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. |
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. > > |
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. >> >> > > > |
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. >>> >>> >> >> > > |
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. >>>> >>>> >>> >>> >> >> > > > |
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. >>>>> >>>>> >>>> >>> >> >> > > > > |
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. >>>>>> >>>>>> >>> >> >> >> > > |
#1 is to determine were to direct the specific email
<mca mail-rule-name="EmailOrdersRule"> <condition-header header-name="Return-Path:" operator="matches" value="[hidden email]"/> <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. >>>>>>> >>>>>>> >>>> >>> >>> >>> >> >> > > > |
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="[hidden email]"/> > <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. >>>>>>>> >>>>>>>> >>>> >>>> >>> >> >> > > > > |
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 "[hidden email]" 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 "[hidden email]" 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 <[hidden email]> wrote: > From: BJ Freeman <[hidden email]> > Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions. > To: [hidden email] > 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="[hidden email]"/> > > <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. > >>>>>>>> > >>>>>>>> > >>>> > >>>> > >>> > >> > >> > > > > > > > > |
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 "[hidden email]" 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 "[hidden email]" 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 <[hidden email]> wrote: > >> From: BJ Freeman <[hidden email]> >> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions. >> To: [hidden email] >> 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="[hidden email]"/> >>> <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. >>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>> >>> >>> > > > > > > |
In reply to this post by Adrian Crum-2
[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 "[hidden email]" 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 "[hidden email]" 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 <[hidden email]> wrote: > >> From: BJ Freeman <[hidden email]> >> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions. >> To: [hidden email] >> 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="[hidden email]"/> >>> <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. >>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>> >>> >>> > > > > > > |
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 "[hidden email]" 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 "[hidden email]" 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 <[hidden email]> wrote: >> >>> From: BJ Freeman <[hidden email]> >>> Subject: Re: ServiceMcaCondition adding conditionals and multipline conditions. >>> To: [hidden email] >>> 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="[hidden email]"/> >>>> <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. >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> >> >> >> >> >> > > > > |
Free forum by Nabble | Edit this page |