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 "[EMAIL PROTECTED]" 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 "[EMAIL PROTECTED]" 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 <[EMAIL PROTECTED]> wrote: > From: BJ Freeman <[EMAIL PROTECTED]> > Subject: Re: ServiceMcaCondition adding conditionals and multipline > conditions. > To: [email protected] > 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="[EMAIL PROTECTED]"/> > > <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. > >>>>>>>> > >>>>>>>> > >>>> > >>>> > >>> > >> > >> > > > > > > > >
