You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by BJ Freeman <bj...@free-man.net> on 2008/09/30 21:35:59 UTC
ServiceMcaCondition adding conditionals and multipline conditions.
if seemed pretty simple to add the conditionals.
but looking a the decision tree it looks like is an or'ed condition.
if I have two condition for the same header or field and one of them is
true then they will all be true.
The question is, is expanding the conditions to accept and and or
condition acceptable. this would include a grouping of each condition
like in an If statement.
rationale:
a lot of emails have parts of a field or header that needs to be looked
at. for instance
subject: order #13950 from yst-1309
to parse you want
[contain order
and
contain yst]
or
not-contain Re:
BTW any hints on how to define a group of condition in the xsd would help.
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
ah, I was asking if there was any opposition to the change.
I have it mostly done.
thanks.
Adrian Crum sent the following on 9/30/2008 5:44 PM:
> Until someone is willing to to make those changes, you're stuck with the tools at hand. That's why I suggested moving your parsing logic to the processing logic you already have.
>
> Your example:
>
> If an email has a return path that contains "orders@store.yahoo.com" and/or (not sure which) the email is from "Yahoo" then it's a Yahoo email - send it to ProcessYahooEmailOrders.
>
> My suggestion:
>
> Send incoming email to ProcessYahooEmailOrders. If the email has a return path that contains "orders@store.yahoo.com" and/or the email is from "Yahoo" then it's a Yahoo email - continue processing. Else return.
>
> The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code.
>
> -Adrian
>
> --- On Tue, 9/30/08, BJ Freeman <bj...@free-man.net> wrote:
>
>> From: BJ Freeman <bj...@free-man.net>
>> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions.
>> To: dev@ofbiz.apache.org
>> Date: Tuesday, September 30, 2008, 4:26 PM
>> just to recap my question had to do with modifying the
>> ServiceMcaCondition.java
>> to handle a contians operator and allowing more than one
>> condition for
>> fields and headers.
>> Nothing specific about the type of email like fedex or ups.
>>
>>
>> BJ Freeman sent the following on 9/30/2008 3:39 PM:
>>> #1 is to determine were to direct the specific email
>>> <mca
>> mail-rule-name="EmailOrdersRule">
>>> <condition-header
>> header-name="Return-Path:"
>> operator="matches"
>>>
>> value="orders@store.yahoo.com"/>
>>> <condition-field
>> field-name="subject"
>> operator="not-contains"
>>> value="RE:"/>
>>> <condition-field
>> field-name="subject" operator="contains"
>>> value="Order*"/>
>>> <condition-field
>> field-name="from" operator="contains"
>>> value="Yahoo"/>
>>> <action
>> service="ProcessYahooEmailOrders"
>> mode="sync"/>
>>> </mca>
>>>
>>> that is my uncerstainding of mCA.
>>> otherwise why not just do a way with it?
>>> #2 not sure the function of #2 since that can be
>> filtered by the mca.
>>> Why bury the filter algorithms in code. isn't that
>> what MCA are for?
>>> #3is done with the MCA dispatch. and is more flexible
>> than burying it in
>>> code.
>>>
>>> Adrian Crum sent the following on 9/30/2008 3:23 PM:
>>>> From a design perspective, my preference would be
>> to have a good
>>>> separation of concern. Something like:
>>>>
>>>> 1. MCA triggers service call
>>>> 2. Service pre-parses mail - drops obvious rejects
>>>> 3. Service forwards mail to a processing chain:
>>>>
>>>> Pre-Parsed Mail -> Fedex Processor -> UPS
>> Processor -> Import Processor
>>>> -> etc.
>>>>
>>>> The disadvantage to having the parsing done in the
>> MCA XML code is you
>>>> end up cross-cutting code (spaghetti code). For
>> example, Fedex-specific
>>>> code would be in your Fedex process AND in the MCA
>> XML code. It would be
>>>> better to keep all Fedex code in one place.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> BJ Freeman wrote:
>>>>> if you look at the msg about checking for
>> duplicates in the user ML you
>>>>> can see that any thing that will take longer
>> will eventually clogs the
>>>>> system.
>>>>> Most of my clients have hundreds of emails
>> from shippers
>>>>> (fulfillment/dropshippers) and suppliers about
>> status of drop ship
>>>>> inventory.
>>>>> So I would like to make the process as
>> efficient as possible but having
>>>>> the mca get to the correct parsing.
>>>>>
>>>>>
>>>>>
>>>>> BJ Freeman sent the following on 9/30/2008
>> 1:23 PM:
>>>>>> routines are in java. and meant to parse
>> the email. they never get put
>>>>>> in the communications event.
>>>>>>
>>>>>> Adrian Crum sent the following on
>> 9/30/2008 1:13 PM:
>>>>>>> What are the processes written in? Are
>> they services? If yes, then you
>>>>>>> could set up a service group and have
>> the email go from service to
>>>>>>> service - each service acting on the
>> email accordingly.
>>>>>>> -Adrian
>>>>>>>
>>>>>>> BJ Freeman wrote:
>>>>>>>> thanks
>>>>>>>> but I have many processes that are
>> based on the email subject and or
>>>>>>>> sender. Fedex notification, UPS
>> Notifications, Order of different
>>>>>>>> formats
>>>>>>>> Import routies, etc.
>>>>>>>> would like to do this in the mca
>> so I don't have to write this in java
>>>>>>>> code then do the same thing.
>>>>>>>>
>>>>>>>> Adrian Crum sent the following on
>> 9/30/2008 12:47 PM:
>>>>>>>>> The way I handled it here was
>> to have a simpler condition that
>>>>>>>>> sent the
>>>>>>>>> email into a processor that
>> did additional evaluations on the email.
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>> if seemed pretty simple to
>> add the conditionals.
>>>>>>>>>> but looking a the decision
>> tree it looks like is an or'ed condition.
>>>>>>>>>> if I have two condition
>> for the same header or field and one of
>>>>>>>>>> them is
>>>>>>>>>> true then they will all be
>> true.
>>>>>>>>>> The question is, is
>> expanding the conditions to accept and and or
>>>>>>>>>> condition acceptable. this
>> would include a grouping of each
>>>>>>>>>> condition
>>>>>>>>>> like in an If statement.
>>>>>>>>>>
>>>>>>>>>> rationale:
>>>>>>>>>> a lot of emails have parts
>> of a field or header that needs to be
>>>>>>>>>> looked
>>>>>>>>>> at. for instance
>>>>>>>>>> subject: order #13950 from
>> yst-1309
>>>>>>>>>> to parse you want
>>>>>>>>>> [contain order
>>>>>>>>>> and
>>>>>>>>>> contain yst]
>>>>>>>>>> or
>>>>>>>>>> not-contain Re:
>>>>>>>>>>
>>>>>>>>>> BTW any hints on how to
>> define a group of condition in the xsd would
>>>>>>>>>> help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
the mca I am using is in the yahoo directory.
so I am not proposing to put yahoo mca in the trunk.
I do have a shippers mca that deals with ups, fedex, dhl.
BJ Freeman sent the following on 9/30/2008 7:43 PM:
> [The point I was trying to make is that the decision of whether or not
> an email is a Yahoo email has to be made *somewhere* - so why not keep
> Yahoo-related code in one place? Your approach scatters the
> Yahoo-related code.]
>
> to me putting email processing in the yahoo code is squattering the
> email processing code.
>
> guess it is a matter of what should be where. to me it is a email till
> it get dispatched. So I treat it as a email.
> to me email processing, related to sorting belongs in the MCA. This
> philosophy follows in mail servers as well, like james.
>
> then all the specific code for that email processing should be in the
> related code, the email is dispatched to, like the parsing of the email.
>
>
>
>
>
> Adrian Crum sent the following on 9/30/2008 5:44 PM:
>> Until someone is willing to to make those changes, you're stuck with the tools at hand. That's why I suggested moving your parsing logic to the processing logic you already have.
>>
>> Your example:
>>
>> If an email has a return path that contains "orders@store.yahoo.com" and/or (not sure which) the email is from "Yahoo" then it's a Yahoo email - send it to ProcessYahooEmailOrders.
>>
>> My suggestion:
>>
>> Send incoming email to ProcessYahooEmailOrders. If the email has a return path that contains "orders@store.yahoo.com" and/or the email is from "Yahoo" then it's a Yahoo email - continue processing. Else return.
>>
>> The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code.
>>
>> -Adrian
>>
>> --- On Tue, 9/30/08, BJ Freeman <bj...@free-man.net> wrote:
>>
>>> From: BJ Freeman <bj...@free-man.net>
>>> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions.
>>> To: dev@ofbiz.apache.org
>>> Date: Tuesday, September 30, 2008, 4:26 PM
>>> just to recap my question had to do with modifying the
>>> ServiceMcaCondition.java
>>> to handle a contians operator and allowing more than one
>>> condition for
>>> fields and headers.
>>> Nothing specific about the type of email like fedex or ups.
>>>
>>>
>>> BJ Freeman sent the following on 9/30/2008 3:39 PM:
>>>> #1 is to determine were to direct the specific email
>>>> <mca
>>> mail-rule-name="EmailOrdersRule">
>>>> <condition-header
>>> header-name="Return-Path:"
>>> operator="matches"
>>>>
>>> value="orders@store.yahoo.com"/>
>>>> <condition-field
>>> field-name="subject"
>>> operator="not-contains"
>>>> value="RE:"/>
>>>> <condition-field
>>> field-name="subject" operator="contains"
>>>> value="Order*"/>
>>>> <condition-field
>>> field-name="from" operator="contains"
>>>> value="Yahoo"/>
>>>> <action
>>> service="ProcessYahooEmailOrders"
>>> mode="sync"/>
>>>> </mca>
>>>>
>>>> that is my uncerstainding of mCA.
>>>> otherwise why not just do a way with it?
>>>> #2 not sure the function of #2 since that can be
>>> filtered by the mca.
>>>> Why bury the filter algorithms in code. isn't that
>>> what MCA are for?
>>>> #3is done with the MCA dispatch. and is more flexible
>>> than burying it in
>>>> code.
>>>>
>>>> Adrian Crum sent the following on 9/30/2008 3:23 PM:
>>>>> From a design perspective, my preference would be
>>> to have a good
>>>>> separation of concern. Something like:
>>>>>
>>>>> 1. MCA triggers service call
>>>>> 2. Service pre-parses mail - drops obvious rejects
>>>>> 3. Service forwards mail to a processing chain:
>>>>>
>>>>> Pre-Parsed Mail -> Fedex Processor -> UPS
>>> Processor -> Import Processor
>>>>> -> etc.
>>>>>
>>>>> The disadvantage to having the parsing done in the
>>> MCA XML code is you
>>>>> end up cross-cutting code (spaghetti code). For
>>> example, Fedex-specific
>>>>> code would be in your Fedex process AND in the MCA
>>> XML code. It would be
>>>>> better to keep all Fedex code in one place.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> BJ Freeman wrote:
>>>>>> if you look at the msg about checking for
>>> duplicates in the user ML you
>>>>>> can see that any thing that will take longer
>>> will eventually clogs the
>>>>>> system.
>>>>>> Most of my clients have hundreds of emails
>>> from shippers
>>>>>> (fulfillment/dropshippers) and suppliers about
>>> status of drop ship
>>>>>> inventory.
>>>>>> So I would like to make the process as
>>> efficient as possible but having
>>>>>> the mca get to the correct parsing.
>>>>>>
>>>>>>
>>>>>>
>>>>>> BJ Freeman sent the following on 9/30/2008
>>> 1:23 PM:
>>>>>>> routines are in java. and meant to parse
>>> the email. they never get put
>>>>>>> in the communications event.
>>>>>>>
>>>>>>> Adrian Crum sent the following on
>>> 9/30/2008 1:13 PM:
>>>>>>>> What are the processes written in? Are
>>> they services? If yes, then you
>>>>>>>> could set up a service group and have
>>> the email go from service to
>>>>>>>> service - each service acting on the
>>> email accordingly.
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> BJ Freeman wrote:
>>>>>>>>> thanks
>>>>>>>>> but I have many processes that are
>>> based on the email subject and or
>>>>>>>>> sender. Fedex notification, UPS
>>> Notifications, Order of different
>>>>>>>>> formats
>>>>>>>>> Import routies, etc.
>>>>>>>>> would like to do this in the mca
>>> so I don't have to write this in java
>>>>>>>>> code then do the same thing.
>>>>>>>>>
>>>>>>>>> Adrian Crum sent the following on
>>> 9/30/2008 12:47 PM:
>>>>>>>>>> The way I handled it here was
>>> to have a simpler condition that
>>>>>>>>>> sent the
>>>>>>>>>> email into a processor that
>>> did additional evaluations on the email.
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>> if seemed pretty simple to
>>> add the conditionals.
>>>>>>>>>>> but looking a the decision
>>> tree it looks like is an or'ed condition.
>>>>>>>>>>> if I have two condition
>>> for the same header or field and one of
>>>>>>>>>>> them is
>>>>>>>>>>> true then they will all be
>>> true.
>>>>>>>>>>> The question is, is
>>> expanding the conditions to accept and and or
>>>>>>>>>>> condition acceptable. this
>>> would include a grouping of each
>>>>>>>>>>> condition
>>>>>>>>>>> like in an If statement.
>>>>>>>>>>>
>>>>>>>>>>> rationale:
>>>>>>>>>>> a lot of emails have parts
>>> of a field or header that needs to be
>>>>>>>>>>> looked
>>>>>>>>>>> at. for instance
>>>>>>>>>>> subject: order #13950 from
>>> yst-1309
>>>>>>>>>>> to parse you want
>>>>>>>>>>> [contain order
>>>>>>>>>>> and
>>>>>>>>>>> contain yst]
>>>>>>>>>>> or
>>>>>>>>>>> not-contain Re:
>>>>>>>>>>>
>>>>>>>>>>> BTW any hints on how to
>>> define a group of condition in the xsd would
>>>>>>>>>>> help.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
[The point I was trying to make is that the decision of whether or not
an email is a Yahoo email has to be made *somewhere* - so why not keep
Yahoo-related code in one place? Your approach scatters the
Yahoo-related code.]
to me putting email processing in the yahoo code is squattering the
email processing code.
guess it is a matter of what should be where. to me it is a email till
it get dispatched. So I treat it as a email.
to me email processing, related to sorting belongs in the MCA. This
philosophy follows in mail servers as well, like james.
then all the specific code for that email processing should be in the
related code, the email is dispatched to, like the parsing of the email.
Adrian Crum sent the following on 9/30/2008 5:44 PM:
> Until someone is willing to to make those changes, you're stuck with the tools at hand. That's why I suggested moving your parsing logic to the processing logic you already have.
>
> Your example:
>
> If an email has a return path that contains "orders@store.yahoo.com" and/or (not sure which) the email is from "Yahoo" then it's a Yahoo email - send it to ProcessYahooEmailOrders.
>
> My suggestion:
>
> Send incoming email to ProcessYahooEmailOrders. If the email has a return path that contains "orders@store.yahoo.com" and/or the email is from "Yahoo" then it's a Yahoo email - continue processing. Else return.
>
> The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code.
>
> -Adrian
>
> --- On Tue, 9/30/08, BJ Freeman <bj...@free-man.net> wrote:
>
>> From: BJ Freeman <bj...@free-man.net>
>> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions.
>> To: dev@ofbiz.apache.org
>> Date: Tuesday, September 30, 2008, 4:26 PM
>> just to recap my question had to do with modifying the
>> ServiceMcaCondition.java
>> to handle a contians operator and allowing more than one
>> condition for
>> fields and headers.
>> Nothing specific about the type of email like fedex or ups.
>>
>>
>> BJ Freeman sent the following on 9/30/2008 3:39 PM:
>>> #1 is to determine were to direct the specific email
>>> <mca
>> mail-rule-name="EmailOrdersRule">
>>> <condition-header
>> header-name="Return-Path:"
>> operator="matches"
>>>
>> value="orders@store.yahoo.com"/>
>>> <condition-field
>> field-name="subject"
>> operator="not-contains"
>>> value="RE:"/>
>>> <condition-field
>> field-name="subject" operator="contains"
>>> value="Order*"/>
>>> <condition-field
>> field-name="from" operator="contains"
>>> value="Yahoo"/>
>>> <action
>> service="ProcessYahooEmailOrders"
>> mode="sync"/>
>>> </mca>
>>>
>>> that is my uncerstainding of mCA.
>>> otherwise why not just do a way with it?
>>> #2 not sure the function of #2 since that can be
>> filtered by the mca.
>>> Why bury the filter algorithms in code. isn't that
>> what MCA are for?
>>> #3is done with the MCA dispatch. and is more flexible
>> than burying it in
>>> code.
>>>
>>> Adrian Crum sent the following on 9/30/2008 3:23 PM:
>>>> From a design perspective, my preference would be
>> to have a good
>>>> separation of concern. Something like:
>>>>
>>>> 1. MCA triggers service call
>>>> 2. Service pre-parses mail - drops obvious rejects
>>>> 3. Service forwards mail to a processing chain:
>>>>
>>>> Pre-Parsed Mail -> Fedex Processor -> UPS
>> Processor -> Import Processor
>>>> -> etc.
>>>>
>>>> The disadvantage to having the parsing done in the
>> MCA XML code is you
>>>> end up cross-cutting code (spaghetti code). For
>> example, Fedex-specific
>>>> code would be in your Fedex process AND in the MCA
>> XML code. It would be
>>>> better to keep all Fedex code in one place.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> BJ Freeman wrote:
>>>>> if you look at the msg about checking for
>> duplicates in the user ML you
>>>>> can see that any thing that will take longer
>> will eventually clogs the
>>>>> system.
>>>>> Most of my clients have hundreds of emails
>> from shippers
>>>>> (fulfillment/dropshippers) and suppliers about
>> status of drop ship
>>>>> inventory.
>>>>> So I would like to make the process as
>> efficient as possible but having
>>>>> the mca get to the correct parsing.
>>>>>
>>>>>
>>>>>
>>>>> BJ Freeman sent the following on 9/30/2008
>> 1:23 PM:
>>>>>> routines are in java. and meant to parse
>> the email. they never get put
>>>>>> in the communications event.
>>>>>>
>>>>>> Adrian Crum sent the following on
>> 9/30/2008 1:13 PM:
>>>>>>> What are the processes written in? Are
>> they services? If yes, then you
>>>>>>> could set up a service group and have
>> the email go from service to
>>>>>>> service - each service acting on the
>> email accordingly.
>>>>>>> -Adrian
>>>>>>>
>>>>>>> BJ Freeman wrote:
>>>>>>>> thanks
>>>>>>>> but I have many processes that are
>> based on the email subject and or
>>>>>>>> sender. Fedex notification, UPS
>> Notifications, Order of different
>>>>>>>> formats
>>>>>>>> Import routies, etc.
>>>>>>>> would like to do this in the mca
>> so I don't have to write this in java
>>>>>>>> code then do the same thing.
>>>>>>>>
>>>>>>>> Adrian Crum sent the following on
>> 9/30/2008 12:47 PM:
>>>>>>>>> The way I handled it here was
>> to have a simpler condition that
>>>>>>>>> sent the
>>>>>>>>> email into a processor that
>> did additional evaluations on the email.
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>> if seemed pretty simple to
>> add the conditionals.
>>>>>>>>>> but looking a the decision
>> tree it looks like is an or'ed condition.
>>>>>>>>>> if I have two condition
>> for the same header or field and one of
>>>>>>>>>> them is
>>>>>>>>>> true then they will all be
>> true.
>>>>>>>>>> The question is, is
>> expanding the conditions to accept and and or
>>>>>>>>>> condition acceptable. this
>> would include a grouping of each
>>>>>>>>>> condition
>>>>>>>>>> like in an If statement.
>>>>>>>>>>
>>>>>>>>>> rationale:
>>>>>>>>>> a lot of emails have parts
>> of a field or header that needs to be
>>>>>>>>>> looked
>>>>>>>>>> at. for instance
>>>>>>>>>> subject: order #13950 from
>> yst-1309
>>>>>>>>>> to parse you want
>>>>>>>>>> [contain order
>>>>>>>>>> and
>>>>>>>>>> contain yst]
>>>>>>>>>> or
>>>>>>>>>> not-contain Re:
>>>>>>>>>>
>>>>>>>>>> BTW any hints on how to
>> define a group of condition in the xsd would
>>>>>>>>>> help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by Adrian Crum <ad...@yahoo.com>.
Until someone is willing to to make those changes, you're stuck with the tools at hand. That's why I suggested moving your parsing logic to the processing logic you already have.
Your example:
If an email has a return path that contains "orders@store.yahoo.com" and/or (not sure which) the email is from "Yahoo" then it's a Yahoo email - send it to ProcessYahooEmailOrders.
My suggestion:
Send incoming email to ProcessYahooEmailOrders. If the email has a return path that contains "orders@store.yahoo.com" and/or the email is from "Yahoo" then it's a Yahoo email - continue processing. Else return.
The point I was trying to make is that the decision of whether or not an email is a Yahoo email has to be made *somewhere* - so why not keep Yahoo-related code in one place? Your approach scatters the Yahoo-related code.
-Adrian
--- On Tue, 9/30/08, BJ Freeman <bj...@free-man.net> wrote:
> From: BJ Freeman <bj...@free-man.net>
> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions.
> To: dev@ofbiz.apache.org
> Date: Tuesday, September 30, 2008, 4:26 PM
> just to recap my question had to do with modifying the
> ServiceMcaCondition.java
> to handle a contians operator and allowing more than one
> condition for
> fields and headers.
> Nothing specific about the type of email like fedex or ups.
>
>
> BJ Freeman sent the following on 9/30/2008 3:39 PM:
> > #1 is to determine were to direct the specific email
> > <mca
> mail-rule-name="EmailOrdersRule">
> > <condition-header
> header-name="Return-Path:"
> operator="matches"
> >
> value="orders@store.yahoo.com"/>
> > <condition-field
> field-name="subject"
> operator="not-contains"
> > value="RE:"/>
> > <condition-field
> field-name="subject" operator="contains"
> > value="Order*"/>
> > <condition-field
> field-name="from" operator="contains"
> > value="Yahoo"/>
> > <action
> service="ProcessYahooEmailOrders"
> mode="sync"/>
> > </mca>
> >
> > that is my uncerstainding of mCA.
> > otherwise why not just do a way with it?
> > #2 not sure the function of #2 since that can be
> filtered by the mca.
> > Why bury the filter algorithms in code. isn't that
> what MCA are for?
> >
> > #3is done with the MCA dispatch. and is more flexible
> than burying it in
> > code.
> >
> > Adrian Crum sent the following on 9/30/2008 3:23 PM:
> >> From a design perspective, my preference would be
> to have a good
> >> separation of concern. Something like:
> >>
> >> 1. MCA triggers service call
> >> 2. Service pre-parses mail - drops obvious rejects
> >> 3. Service forwards mail to a processing chain:
> >>
> >> Pre-Parsed Mail -> Fedex Processor -> UPS
> Processor -> Import Processor
> >> -> etc.
> >>
> >> The disadvantage to having the parsing done in the
> MCA XML code is you
> >> end up cross-cutting code (spaghetti code). For
> example, Fedex-specific
> >> code would be in your Fedex process AND in the MCA
> XML code. It would be
> >> better to keep all Fedex code in one place.
> >>
> >> -Adrian
> >>
> >>
> >> BJ Freeman wrote:
> >>> if you look at the msg about checking for
> duplicates in the user ML you
> >>> can see that any thing that will take longer
> will eventually clogs the
> >>> system.
> >>> Most of my clients have hundreds of emails
> from shippers
> >>> (fulfillment/dropshippers) and suppliers about
> status of drop ship
> >>> inventory.
> >>> So I would like to make the process as
> efficient as possible but having
> >>> the mca get to the correct parsing.
> >>>
> >>>
> >>>
> >>> BJ Freeman sent the following on 9/30/2008
> 1:23 PM:
> >>>> routines are in java. and meant to parse
> the email. they never get put
> >>>> in the communications event.
> >>>>
> >>>> Adrian Crum sent the following on
> 9/30/2008 1:13 PM:
> >>>>> What are the processes written in? Are
> they services? If yes, then you
> >>>>> could set up a service group and have
> the email go from service to
> >>>>> service - each service acting on the
> email accordingly.
> >>>>>
> >>>>> -Adrian
> >>>>>
> >>>>> BJ Freeman wrote:
> >>>>>> thanks
> >>>>>> but I have many processes that are
> based on the email subject and or
> >>>>>> sender. Fedex notification, UPS
> Notifications, Order of different
> >>>>>> formats
> >>>>>> Import routies, etc.
> >>>>>> would like to do this in the mca
> so I don't have to write this in java
> >>>>>> code then do the same thing.
> >>>>>>
> >>>>>> Adrian Crum sent the following on
> 9/30/2008 12:47 PM:
> >>>>>>> The way I handled it here was
> to have a simpler condition that
> >>>>>>> sent the
> >>>>>>> email into a processor that
> did additional evaluations on the email.
> >>>>>>>
> >>>>>>> -Adrian
> >>>>>>>
> >>>>>>> BJ Freeman wrote:
> >>>>>>>> if seemed pretty simple to
> add the conditionals.
> >>>>>>>> but looking a the decision
> tree it looks like is an or'ed condition.
> >>>>>>>> if I have two condition
> for the same header or field and one of
> >>>>>>>> them is
> >>>>>>>> true then they will all be
> true.
> >>>>>>>>
> >>>>>>>> The question is, is
> expanding the conditions to accept and and or
> >>>>>>>> condition acceptable. this
> would include a grouping of each
> >>>>>>>> condition
> >>>>>>>> like in an If statement.
> >>>>>>>>
> >>>>>>>> rationale:
> >>>>>>>> a lot of emails have parts
> of a field or header that needs to be
> >>>>>>>> looked
> >>>>>>>> at. for instance
> >>>>>>>> subject: order #13950 from
> yst-1309
> >>>>>>>> to parse you want
> >>>>>>>> [contain order
> >>>>>>>> and
> >>>>>>>> contain yst]
> >>>>>>>> or
> >>>>>>>> not-contain Re:
> >>>>>>>>
> >>>>>>>> BTW any hints on how to
> define a group of condition in the xsd would
> >>>>>>>> help.
> >>>>>>>>
> >>>>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> >
> >
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
just to recap my question had to do with modifying the
ServiceMcaCondition.java
to handle a contians operator and allowing more than one condition for
fields and headers.
Nothing specific about the type of email like fedex or ups.
BJ Freeman sent the following on 9/30/2008 3:39 PM:
> #1 is to determine were to direct the specific email
> <mca mail-rule-name="EmailOrdersRule">
> <condition-header header-name="Return-Path:" operator="matches"
> value="orders@store.yahoo.com"/>
> <condition-field field-name="subject" operator="not-contains"
> value="RE:"/>
> <condition-field field-name="subject" operator="contains"
> value="Order*"/>
> <condition-field field-name="from" operator="contains"
> value="Yahoo"/>
> <action service="ProcessYahooEmailOrders" mode="sync"/>
> </mca>
>
> that is my uncerstainding of mCA.
> otherwise why not just do a way with it?
> #2 not sure the function of #2 since that can be filtered by the mca.
> Why bury the filter algorithms in code. isn't that what MCA are for?
>
> #3is done with the MCA dispatch. and is more flexible than burying it in
> code.
>
> Adrian Crum sent the following on 9/30/2008 3:23 PM:
>> From a design perspective, my preference would be to have a good
>> separation of concern. Something like:
>>
>> 1. MCA triggers service call
>> 2. Service pre-parses mail - drops obvious rejects
>> 3. Service forwards mail to a processing chain:
>>
>> Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor
>> -> etc.
>>
>> The disadvantage to having the parsing done in the MCA XML code is you
>> end up cross-cutting code (spaghetti code). For example, Fedex-specific
>> code would be in your Fedex process AND in the MCA XML code. It would be
>> better to keep all Fedex code in one place.
>>
>> -Adrian
>>
>>
>> BJ Freeman wrote:
>>> if you look at the msg about checking for duplicates in the user ML you
>>> can see that any thing that will take longer will eventually clogs the
>>> system.
>>> Most of my clients have hundreds of emails from shippers
>>> (fulfillment/dropshippers) and suppliers about status of drop ship
>>> inventory.
>>> So I would like to make the process as efficient as possible but having
>>> the mca get to the correct parsing.
>>>
>>>
>>>
>>> BJ Freeman sent the following on 9/30/2008 1:23 PM:
>>>> routines are in java. and meant to parse the email. they never get put
>>>> in the communications event.
>>>>
>>>> Adrian Crum sent the following on 9/30/2008 1:13 PM:
>>>>> What are the processes written in? Are they services? If yes, then you
>>>>> could set up a service group and have the email go from service to
>>>>> service - each service acting on the email accordingly.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> BJ Freeman wrote:
>>>>>> thanks
>>>>>> but I have many processes that are based on the email subject and or
>>>>>> sender. Fedex notification, UPS Notifications, Order of different
>>>>>> formats
>>>>>> Import routies, etc.
>>>>>> would like to do this in the mca so I don't have to write this in java
>>>>>> code then do the same thing.
>>>>>>
>>>>>> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>>>>>>> The way I handled it here was to have a simpler condition that
>>>>>>> sent the
>>>>>>> email into a processor that did additional evaluations on the email.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> BJ Freeman wrote:
>>>>>>>> if seemed pretty simple to add the conditionals.
>>>>>>>> but looking a the decision tree it looks like is an or'ed condition.
>>>>>>>> if I have two condition for the same header or field and one of
>>>>>>>> them is
>>>>>>>> true then they will all be true.
>>>>>>>>
>>>>>>>> The question is, is expanding the conditions to accept and and or
>>>>>>>> condition acceptable. this would include a grouping of each
>>>>>>>> condition
>>>>>>>> like in an If statement.
>>>>>>>>
>>>>>>>> rationale:
>>>>>>>> a lot of emails have parts of a field or header that needs to be
>>>>>>>> looked
>>>>>>>> at. for instance
>>>>>>>> subject: order #13950 from yst-1309
>>>>>>>> to parse you want
>>>>>>>> [contain order
>>>>>>>> and
>>>>>>>> contain yst]
>>>>>>>> or
>>>>>>>> not-contain Re:
>>>>>>>>
>>>>>>>> BTW any hints on how to define a group of condition in the xsd would
>>>>>>>> help.
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
#1 is to determine were to direct the specific email
<mca mail-rule-name="EmailOrdersRule">
<condition-header header-name="Return-Path:" operator="matches"
value="orders@store.yahoo.com"/>
<condition-field field-name="subject" operator="not-contains"
value="RE:"/>
<condition-field field-name="subject" operator="contains"
value="Order*"/>
<condition-field field-name="from" operator="contains"
value="Yahoo"/>
<action service="ProcessYahooEmailOrders" mode="sync"/>
</mca>
that is my uncerstainding of mCA.
otherwise why not just do a way with it?
#2 not sure the function of #2 since that can be filtered by the mca.
Why bury the filter algorithms in code. isn't that what MCA are for?
#3is done with the MCA dispatch. and is more flexible than burying it in
code.
Adrian Crum sent the following on 9/30/2008 3:23 PM:
> From a design perspective, my preference would be to have a good
> separation of concern. Something like:
>
> 1. MCA triggers service call
> 2. Service pre-parses mail - drops obvious rejects
> 3. Service forwards mail to a processing chain:
>
> Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor
> -> etc.
>
> The disadvantage to having the parsing done in the MCA XML code is you
> end up cross-cutting code (spaghetti code). For example, Fedex-specific
> code would be in your Fedex process AND in the MCA XML code. It would be
> better to keep all Fedex code in one place.
>
> -Adrian
>
>
> BJ Freeman wrote:
>> if you look at the msg about checking for duplicates in the user ML you
>> can see that any thing that will take longer will eventually clogs the
>> system.
>> Most of my clients have hundreds of emails from shippers
>> (fulfillment/dropshippers) and suppliers about status of drop ship
>> inventory.
>> So I would like to make the process as efficient as possible but having
>> the mca get to the correct parsing.
>>
>>
>>
>> BJ Freeman sent the following on 9/30/2008 1:23 PM:
>>> routines are in java. and meant to parse the email. they never get put
>>> in the communications event.
>>>
>>> Adrian Crum sent the following on 9/30/2008 1:13 PM:
>>>> What are the processes written in? Are they services? If yes, then you
>>>> could set up a service group and have the email go from service to
>>>> service - each service acting on the email accordingly.
>>>>
>>>> -Adrian
>>>>
>>>> BJ Freeman wrote:
>>>>> thanks
>>>>> but I have many processes that are based on the email subject and or
>>>>> sender. Fedex notification, UPS Notifications, Order of different
>>>>> formats
>>>>> Import routies, etc.
>>>>> would like to do this in the mca so I don't have to write this in java
>>>>> code then do the same thing.
>>>>>
>>>>> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>>>>>> The way I handled it here was to have a simpler condition that
>>>>>> sent the
>>>>>> email into a processor that did additional evaluations on the email.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> BJ Freeman wrote:
>>>>>>> if seemed pretty simple to add the conditionals.
>>>>>>> but looking a the decision tree it looks like is an or'ed condition.
>>>>>>> if I have two condition for the same header or field and one of
>>>>>>> them is
>>>>>>> true then they will all be true.
>>>>>>>
>>>>>>> The question is, is expanding the conditions to accept and and or
>>>>>>> condition acceptable. this would include a grouping of each
>>>>>>> condition
>>>>>>> like in an If statement.
>>>>>>>
>>>>>>> rationale:
>>>>>>> a lot of emails have parts of a field or header that needs to be
>>>>>>> looked
>>>>>>> at. for instance
>>>>>>> subject: order #13950 from yst-1309
>>>>>>> to parse you want
>>>>>>> [contain order
>>>>>>> and
>>>>>>> contain yst]
>>>>>>> or
>>>>>>> not-contain Re:
>>>>>>>
>>>>>>> BTW any hints on how to define a group of condition in the xsd would
>>>>>>> help.
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by Adrian Crum <ad...@hlmksw.com>.
From a design perspective, my preference would be to have a good
separation of concern. Something like:
1. MCA triggers service call
2. Service pre-parses mail - drops obvious rejects
3. Service forwards mail to a processing chain:
Pre-Parsed Mail -> Fedex Processor -> UPS Processor -> Import Processor
-> etc.
The disadvantage to having the parsing done in the MCA XML code is you
end up cross-cutting code (spaghetti code). For example, Fedex-specific
code would be in your Fedex process AND in the MCA XML code. It would be
better to keep all Fedex code in one place.
-Adrian
BJ Freeman wrote:
> if you look at the msg about checking for duplicates in the user ML you
> can see that any thing that will take longer will eventually clogs the
> system.
> Most of my clients have hundreds of emails from shippers
> (fulfillment/dropshippers) and suppliers about status of drop ship
> inventory.
> So I would like to make the process as efficient as possible but having
> the mca get to the correct parsing.
>
>
>
> BJ Freeman sent the following on 9/30/2008 1:23 PM:
>> routines are in java. and meant to parse the email. they never get put
>> in the communications event.
>>
>> Adrian Crum sent the following on 9/30/2008 1:13 PM:
>>> What are the processes written in? Are they services? If yes, then you
>>> could set up a service group and have the email go from service to
>>> service - each service acting on the email accordingly.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>> thanks
>>>> but I have many processes that are based on the email subject and or
>>>> sender. Fedex notification, UPS Notifications, Order of different formats
>>>> Import routies, etc.
>>>> would like to do this in the mca so I don't have to write this in java
>>>> code then do the same thing.
>>>>
>>>> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>>>>> The way I handled it here was to have a simpler condition that sent the
>>>>> email into a processor that did additional evaluations on the email.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> BJ Freeman wrote:
>>>>>> if seemed pretty simple to add the conditionals.
>>>>>> but looking a the decision tree it looks like is an or'ed condition.
>>>>>> if I have two condition for the same header or field and one of them is
>>>>>> true then they will all be true.
>>>>>>
>>>>>> The question is, is expanding the conditions to accept and and or
>>>>>> condition acceptable. this would include a grouping of each condition
>>>>>> like in an If statement.
>>>>>>
>>>>>> rationale:
>>>>>> a lot of emails have parts of a field or header that needs to be looked
>>>>>> at. for instance
>>>>>> subject: order #13950 from yst-1309
>>>>>> to parse you want
>>>>>> [contain order
>>>>>> and
>>>>>> contain yst]
>>>>>> or
>>>>>> not-contain Re:
>>>>>>
>>>>>> BTW any hints on how to define a group of condition in the xsd would
>>>>>> help.
>>>>>>
>>>>>>
>>>
>>
>>
>>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
if you look at the msg about checking for duplicates in the user ML you
can see that any thing that will take longer will eventually clogs the
system.
Most of my clients have hundreds of emails from shippers
(fulfillment/dropshippers) and suppliers about status of drop ship
inventory.
So I would like to make the process as efficient as possible but having
the mca get to the correct parsing.
BJ Freeman sent the following on 9/30/2008 1:23 PM:
> routines are in java. and meant to parse the email. they never get put
> in the communications event.
>
> Adrian Crum sent the following on 9/30/2008 1:13 PM:
>> What are the processes written in? Are they services? If yes, then you
>> could set up a service group and have the email go from service to
>> service - each service acting on the email accordingly.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>> thanks
>>> but I have many processes that are based on the email subject and or
>>> sender. Fedex notification, UPS Notifications, Order of different formats
>>> Import routies, etc.
>>> would like to do this in the mca so I don't have to write this in java
>>> code then do the same thing.
>>>
>>> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>>>> The way I handled it here was to have a simpler condition that sent the
>>>> email into a processor that did additional evaluations on the email.
>>>>
>>>> -Adrian
>>>>
>>>> BJ Freeman wrote:
>>>>> if seemed pretty simple to add the conditionals.
>>>>> but looking a the decision tree it looks like is an or'ed condition.
>>>>> if I have two condition for the same header or field and one of them is
>>>>> true then they will all be true.
>>>>>
>>>>> The question is, is expanding the conditions to accept and and or
>>>>> condition acceptable. this would include a grouping of each condition
>>>>> like in an If statement.
>>>>>
>>>>> rationale:
>>>>> a lot of emails have parts of a field or header that needs to be looked
>>>>> at. for instance
>>>>> subject: order #13950 from yst-1309
>>>>> to parse you want
>>>>> [contain order
>>>>> and
>>>>> contain yst]
>>>>> or
>>>>> not-contain Re:
>>>>>
>>>>> BTW any hints on how to define a group of condition in the xsd would
>>>>> help.
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
routines are in java. and meant to parse the email. they never get put
in the communications event.
Adrian Crum sent the following on 9/30/2008 1:13 PM:
> What are the processes written in? Are they services? If yes, then you
> could set up a service group and have the email go from service to
> service - each service acting on the email accordingly.
>
> -Adrian
>
> BJ Freeman wrote:
>> thanks
>> but I have many processes that are based on the email subject and or
>> sender. Fedex notification, UPS Notifications, Order of different formats
>> Import routies, etc.
>> would like to do this in the mca so I don't have to write this in java
>> code then do the same thing.
>>
>> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>>> The way I handled it here was to have a simpler condition that sent the
>>> email into a processor that did additional evaluations on the email.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>> if seemed pretty simple to add the conditionals.
>>>> but looking a the decision tree it looks like is an or'ed condition.
>>>> if I have two condition for the same header or field and one of them is
>>>> true then they will all be true.
>>>>
>>>> The question is, is expanding the conditions to accept and and or
>>>> condition acceptable. this would include a grouping of each condition
>>>> like in an If statement.
>>>>
>>>> rationale:
>>>> a lot of emails have parts of a field or header that needs to be looked
>>>> at. for instance
>>>> subject: order #13950 from yst-1309
>>>> to parse you want
>>>> [contain order
>>>> and
>>>> contain yst]
>>>> or
>>>> not-contain Re:
>>>>
>>>> BTW any hints on how to define a group of condition in the xsd would
>>>> help.
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by Adrian Crum <ad...@hlmksw.com>.
What are the processes written in? Are they services? If yes, then you
could set up a service group and have the email go from service to
service - each service acting on the email accordingly.
-Adrian
BJ Freeman wrote:
> thanks
> but I have many processes that are based on the email subject and or
> sender. Fedex notification, UPS Notifications, Order of different formats
> Import routies, etc.
> would like to do this in the mca so I don't have to write this in java
> code then do the same thing.
>
> Adrian Crum sent the following on 9/30/2008 12:47 PM:
>> The way I handled it here was to have a simpler condition that sent the
>> email into a processor that did additional evaluations on the email.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>> if seemed pretty simple to add the conditionals.
>>> but looking a the decision tree it looks like is an or'ed condition.
>>> if I have two condition for the same header or field and one of them is
>>> true then they will all be true.
>>>
>>> The question is, is expanding the conditions to accept and and or
>>> condition acceptable. this would include a grouping of each condition
>>> like in an If statement.
>>>
>>> rationale:
>>> a lot of emails have parts of a field or header that needs to be looked
>>> at. for instance
>>> subject: order #13950 from yst-1309
>>> to parse you want
>>> [contain order
>>> and
>>> contain yst]
>>> or
>>> not-contain Re:
>>>
>>> BTW any hints on how to define a group of condition in the xsd would
>>> help.
>>>
>>>
>>
>>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by BJ Freeman <bj...@free-man.net>.
thanks
but I have many processes that are based on the email subject and or
sender. Fedex notification, UPS Notifications, Order of different formats
Import routies, etc.
would like to do this in the mca so I don't have to write this in java
code then do the same thing.
Adrian Crum sent the following on 9/30/2008 12:47 PM:
> The way I handled it here was to have a simpler condition that sent the
> email into a processor that did additional evaluations on the email.
>
> -Adrian
>
> BJ Freeman wrote:
>> if seemed pretty simple to add the conditionals.
>> but looking a the decision tree it looks like is an or'ed condition.
>> if I have two condition for the same header or field and one of them is
>> true then they will all be true.
>>
>> The question is, is expanding the conditions to accept and and or
>> condition acceptable. this would include a grouping of each condition
>> like in an If statement.
>>
>> rationale:
>> a lot of emails have parts of a field or header that needs to be looked
>> at. for instance
>> subject: order #13950 from yst-1309
>> to parse you want
>> [contain order
>> and
>> contain yst]
>> or
>> not-contain Re:
>>
>> BTW any hints on how to define a group of condition in the xsd would
>> help.
>>
>>
>
>
>
Re: ServiceMcaCondition adding conditionals and multipline conditions.
Posted by Adrian Crum <ad...@hlmksw.com>.
The way I handled it here was to have a simpler condition that sent the
email into a processor that did additional evaluations on the email.
-Adrian
BJ Freeman wrote:
> if seemed pretty simple to add the conditionals.
> but looking a the decision tree it looks like is an or'ed condition.
> if I have two condition for the same header or field and one of them is
> true then they will all be true.
>
> The question is, is expanding the conditions to accept and and or
> condition acceptable. this would include a grouping of each condition
> like in an If statement.
>
> rationale:
> a lot of emails have parts of a field or header that needs to be looked
> at. for instance
> subject: order #13950 from yst-1309
> to parse you want
> [contain order
> and
> contain yst]
> or
> not-contain Re:
>
> BTW any hints on how to define a group of condition in the xsd would help.
>
>