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