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 "[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. >>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>> >>> >>> > > > > > >
