Re: Complex incomming email processing
Good point Shawn! Completely agree. Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24 Fax: 971 75 07 94 <http://www.sm2baleares.es/> SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca <http://es-es.facebook.com/pages/SM2-Baleares/158608627954> <http://twitter.com/#!/SM2Baleares> <http://www.linkedin.com/company/sm2-baleares> La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. On Tue, Apr 17, 2012 at 20:47, Grooms, Frederick W < frederick.w.gro...@xo.com> wrote: > ** > > Another Idea is to put an error handler on the filter that does the Push > to the staging form. This will “absorb” the error and prevent blocking > the creation in the AR System Email Messages form. > > ** ** > > Fred > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Pierson, Shawn > *Sent:* Tuesday, April 17, 2012 1:31 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Complex incomming email processing > > ** ** > > ** > > The one “style” argument I would have with that technique deals > specifically with how to move incoming emails from the AR System Email > Messages Form to the staging form. He uses a Filter, and rightly cautions, > “The Java process that runs the email engine will fail to create an entry > in the “AR System Email Messages” form if the “Run If” fails.” The way I > prefer to avoid that problem is to use an Escalation that runs on a short > interval instead of using a Filter. It is more overhead on the server and > creates a delay, but not so much that it’s a burden, and it completely > eliminates the possibility of you accidentally writing code that messes up > the email engine in some way. > > ** ** > > Again, it’s just a style argument as both work perfectly fine on the happy > path, but I wanted to point out that there may be a safer option with an > Escalation in case you make a mistake as a developer. > > ** ** > > Thanks, > > ** ** > > *Shawn Pierson * > > Remedy Developer | Energy Transfer > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Thad Esser > *Sent:* Monday, April 16, 2012 3:30 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Complex incomming email processing > > ** ** > > ** > > Jose, > > > > William Rentfrow had a blog post a few years ago that I found useful. > There's 5 parts, but part 3 is where the details start: > > > http://williamrentfrow.com/automating-service-bmc-remedy-email-engine-part-3/ > > > Thad > > On Mon, Apr 16, 2012 at 4:07 AM, Jose Huerta > wrote: > > ** > > Hi all, > > ** ** > > I want to receive email from users, perform complex evaluations on it, and > act accordingly. > > ** ** > > For instance, If a pattern like INC is found, then look for > the incident, add the content of the email as a work info, where the sender > must be the user corresponding to the sender address, and generate a > response email. If not, send an error mail. > > ** ** > > Well, My idea is to config an email inbox without parsing and create > filters on AR System Email Messages form. Don't know if it's the better > approach. Comments or suggestions? > > ** ** > > Parsing engine at the email engine seems to be insufficient, because users > can use a lot of formats. > > ** ** > > Thanks, > > ** ** > > Jose Huerta > > http://theremedyforit.com/ > > ** ** > > ** ** > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" <><><><>
Re: Complex incomming email processing
Another Idea is to put an error handler on the filter that does the Push to the staging form. This will "absorb" the error and prevent blocking the creation in the AR System Email Messages form. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Tuesday, April 17, 2012 1:31 PM To: arslist@ARSLIST.ORG Subject: Re: Complex incomming email processing ** The one "style" argument I would have with that technique deals specifically with how to move incoming emails from the AR System Email Messages Form to the staging form. He uses a Filter, and rightly cautions, "The Java process that runs the email engine will fail to create an entry in the "AR System Email Messages" form if the "Run If" fails." The way I prefer to avoid that problem is to use an Escalation that runs on a short interval instead of using a Filter. It is more overhead on the server and creates a delay, but not so much that it's a burden, and it completely eliminates the possibility of you accidentally writing code that messes up the email engine in some way. Again, it's just a style argument as both work perfectly fine on the happy path, but I wanted to point out that there may be a safer option with an Escalation in case you make a mistake as a developer. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser Sent: Monday, April 16, 2012 3:30 PM To: arslist@ARSLIST.ORG Subject: Re: Complex incomming email processing ** Jose, William Rentfrow had a blog post a few years ago that I found useful. There's 5 parts, but part 3 is where the details start: http://williamrentfrow.com/automating-service-bmc-remedy-email-engine-part-3/ Thad On Mon, Apr 16, 2012 at 4:07 AM, Jose Huerta mailto:jose.hue...@sm2baleares.es>> wrote: ** Hi all, I want to receive email from users, perform complex evaluations on it, and act accordingly. For instance, If a pattern like INC is found, then look for the incident, add the content of the email as a work info, where the sender must be the user corresponding to the sender address, and generate a response email. If not, send an error mail. Well, My idea is to config an email inbox without parsing and create filters on AR System Email Messages form. Don't know if it's the better approach. Comments or suggestions? Parsing engine at the email engine seems to be insufficient, because users can use a lot of formats. Thanks, Jose Huerta http://theremedyforit.com/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
The one "style" argument I would have with that technique deals specifically with how to move incoming emails from the AR System Email Messages Form to the staging form. He uses a Filter, and rightly cautions, "The Java process that runs the email engine will fail to create an entry in the "AR System Email Messages" form if the "Run If" fails." The way I prefer to avoid that problem is to use an Escalation that runs on a short interval instead of using a Filter. It is more overhead on the server and creates a delay, but not so much that it's a burden, and it completely eliminates the possibility of you accidentally writing code that messes up the email engine in some way. Again, it's just a style argument as both work perfectly fine on the happy path, but I wanted to point out that there may be a safer option with an Escalation in case you make a mistake as a developer. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser Sent: Monday, April 16, 2012 3:30 PM To: arslist@ARSLIST.ORG Subject: Re: Complex incomming email processing ** Jose, William Rentfrow had a blog post a few years ago that I found useful. There's 5 parts, but part 3 is where the details start: http://williamrentfrow.com/automating-service-bmc-remedy-email-engine-part-3/ Thad On Mon, Apr 16, 2012 at 4:07 AM, Jose Huerta mailto:jose.hue...@sm2baleares.es>> wrote: ** Hi all, I want to receive email from users, perform complex evaluations on it, and act accordingly. For instance, If a pattern like INC is found, then look for the incident, add the content of the email as a work info, where the sender must be the user corresponding to the sender address, and generate a response email. If not, send an error mail. Well, My idea is to config an email inbox without parsing and create filters on AR System Email Messages form. Don't know if it's the better approach. Comments or suggestions? Parsing engine at the email engine seems to be insufficient, because users can use a lot of formats. Thanks, Jose Huerta http://theremedyforit.com/ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
Jose, William Rentfrow had a blog post a few years ago that I found useful. There's 5 parts, but part 3 is where the details start: http://williamrentfrow.com/automating-service-bmc-remedy-email-engine-part-3/ Thad On Mon, Apr 16, 2012 at 4:07 AM, Jose Huerta wrote: > ** > Hi all, > > I want to receive email from users, perform complex evaluations on it, and > act accordingly. > > For instance, If a pattern like INC is found, then look for > the incident, add the content of the email as a work info, where the sender > must be the user corresponding to the sender address, and generate a > response email. If not, send an error mail. > > Well, My idea is to config an email inbox without parsing and create > filters on AR System Email Messages form. Don't know if it's the better > approach. Comments or suggestions? > > Parsing engine at the email engine seems to be insufficient, because users > can use a lot of formats. > > Thanks, > > Jose Huerta > http://theremedyforit.com/ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
Thanks Mahesh for your explanation. As I said, that was my initial plan. Thanks to all. On Mon, Apr 16, 2012 at 19:23, Mahesh wrote: > ** > Here is what you need.. > > Forms: > > 1. Incoming Processor: This form will store all Incoming Messages > and process the message for an Update/ Create action. > > > > 2. Rules: This form will be used to configure rules to create > Requests based on the Incoming message either based on the incoming email > address or a keyword in the subject line. > > > > Example: > > · If the message is from sender X, create an Incident and assign > to Support Group 1. > > · If the message has a "KEYWORD" in the subject line, create a > Work Order and assign to Support Group 2. > > > > Workflow: > > > > 1) Create a Filter on “AR System Email Messages” that will execute > on Submit and push all Incoming Messages to “Incoming Processor” form. > > 2) Filters on “Incoming Processor” > > a. Check the subject line if it contains Incident/ Problem/ Change/ > Request/ Work Order/ Task number. If “Yes”, parse the number and create the > corresponding work log entry. > > b. If the message doesn’t fall into “Update” action, check if there > are any associated rules in “Rules” form for a Create action. > > c. If none of the above, ignore the message. > > Thanks > Mahesh > On Mon, Apr 16, 2012 at 6:31 AM, Jose Huerta > wrote: > >> ** Yes, that was my idea. But not a display only form, but a regular one. >> To store a log of performed actions. Anyway, seems that I'm in the right >> direction. >> >> Thanks, >> >> Jose >> >> >> >> >> On Mon, Apr 16, 2012 at 13:26, Jlbess wrote: >> >>> ** >>> Jose, >>> I typically create a display only form to handle inbound email. Keeping >>> minimal customization on the OOB forms. Just a push field filter from AR >>> System Email Messages. You can then use the custom form to pull data, >>> parse, configure, and push anything where you need it to go without any OOB >>> customization. >>> >>> Jason >>> >>> >>> >>> On Apr 16, 2012, at 7:07 AM, Jose Huerta >>> wrote: >>> >>> ** >>> Hi all, >>> >>> I want to receive email from users, perform complex evaluations on it, >>> and act accordingly. >>> >>> For instance, If a pattern like INC is found, then look for >>> the incident, add the content of the email as a work info, where the sender >>> must be the user corresponding to the sender address, and generate a >>> response email. If not, send an error mail. >>> >>> Well, My idea is to config an email inbox without parsing and create >>> filters on AR System Email Messages form. Don't know if it's the better >>> approach. Comments or suggestions? >>> >>> Parsing engine at the email engine seems to be insufficient, because >>> users can use a lot of formats. >>> >>> Thanks, >>> >>> Jose Huerta >>> http://theremedyforit.com/ >>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >>> >>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
Here is what you need.. Forms: 1. Incoming Processor: This form will store all Incoming Messages and process the message for an Update/ Create action. 2. Rules: This form will be used to configure rules to create Requests based on the Incoming message either based on the incoming email address or a keyword in the subject line. Example: · If the message is from sender X, create an Incident and assign to Support Group 1. · If the message has a "KEYWORD" in the subject line, create a Work Order and assign to Support Group 2. Workflow: 1) Create a Filter on “AR System Email Messages” that will execute on Submit and push all Incoming Messages to “Incoming Processor” form. 2) Filters on “Incoming Processor” a. Check the subject line if it contains Incident/ Problem/ Change/ Request/ Work Order/ Task number. If “Yes”, parse the number and create the corresponding work log entry. b. If the message doesn’t fall into “Update” action, check if there are any associated rules in “Rules” form for a Create action. c. If none of the above, ignore the message. Thanks Mahesh On Mon, Apr 16, 2012 at 6:31 AM, Jose Huerta wrote: > ** Yes, that was my idea. But not a display only form, but a regular one. > To store a log of performed actions. Anyway, seems that I'm in the right > direction. > > Thanks, > > Jose > > > > > On Mon, Apr 16, 2012 at 13:26, Jlbess wrote: > >> ** >> Jose, >> I typically create a display only form to handle inbound email. Keeping >> minimal customization on the OOB forms. Just a push field filter from AR >> System Email Messages. You can then use the custom form to pull data, >> parse, configure, and push anything where you need it to go without any OOB >> customization. >> >> Jason >> >> >> >> On Apr 16, 2012, at 7:07 AM, Jose Huerta >> wrote: >> >> ** >> Hi all, >> >> I want to receive email from users, perform complex evaluations on it, >> and act accordingly. >> >> For instance, If a pattern like INC is found, then look for >> the incident, add the content of the email as a work info, where the sender >> must be the user corresponding to the sender address, and generate a >> response email. If not, send an error mail. >> >> Well, My idea is to config an email inbox without parsing and create >> filters on AR System Email Messages form. Don't know if it's the better >> approach. Comments or suggestions? >> >> Parsing engine at the email engine seems to be insufficient, because >> users can use a lot of formats. >> >> Thanks, >> >> Jose Huerta >> http://theremedyforit.com/ >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
Yes, that was my idea. But not a display only form, but a regular one. To store a log of performed actions. Anyway, seems that I'm in the right direction. Thanks, Jose On Mon, Apr 16, 2012 at 13:26, Jlbess wrote: > ** > Jose, > I typically create a display only form to handle inbound email. Keeping > minimal customization on the OOB forms. Just a push field filter from AR > System Email Messages. You can then use the custom form to pull data, > parse, configure, and push anything where you need it to go without any OOB > customization. > > Jason > > > > On Apr 16, 2012, at 7:07 AM, Jose Huerta > wrote: > > ** > Hi all, > > I want to receive email from users, perform complex evaluations on it, and > act accordingly. > > For instance, If a pattern like INC is found, then look for > the incident, add the content of the email as a work info, where the sender > must be the user corresponding to the sender address, and generate a > response email. If not, send an error mail. > > Well, My idea is to config an email inbox without parsing and create > filters on AR System Email Messages form. Don't know if it's the better > approach. Comments or suggestions? > > Parsing engine at the email engine seems to be insufficient, because users > can use a lot of formats. > > Thanks, > > Jose Huerta > http://theremedyforit.com/ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Complex incomming email processing
Jose, I typically create a display only form to handle inbound email. Keeping minimal customization on the OOB forms. Just a push field filter from AR System Email Messages. You can then use the custom form to pull data, parse, configure, and push anything where you need it to go without any OOB customization. Jason On Apr 16, 2012, at 7:07 AM, Jose Huerta wrote: > ** > Hi all, > > I want to receive email from users, perform complex evaluations on it, and > act accordingly. > > For instance, If a pattern like INC is found, then look for the > incident, add the content of the email as a work info, where the sender must > be the user corresponding to the sender address, and generate a response > email. If not, send an error mail. > > Well, My idea is to config an email inbox without parsing and create filters > on AR System Email Messages form. Don't know if it's the better approach. > Comments or suggestions? > > Parsing engine at the email engine seems to be insufficient, because users > can use a lot of formats. > > Thanks, > > Jose Huerta > http://theremedyforit.com/ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
