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