do you use a scheduler (the server) to fire off the event to check for incoming email?
... or allow clients (users) to check for email on demand?
do you execute the CONNECT TO EMAIL action, process email(s), and then DISCONNECT when finished?
... or never DISCONNECT?
a question to anyone who uses CONNECT TO EMAIL action
a question to anyone who uses CONNECT TO EMAIL action
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.
Jaymer
Aware Programming & Consulting - Tampa FL
Jaymer
Aware Programming & Consulting - Tampa FL
Re: a question to anyone who uses CONNECT TO EMAIL action
VP initialization process with CONNECT TO EMAIL action.
We never disconnect in the production version.
We store the mail settings in an Incoming Email Account Object.
MailCheck attribute determines how often we check for new mail.
We never disconnect in the production version.
We store the mail settings in an Incoming Email Account Object.
MailCheck attribute determines how often we check for new mail.
Re: a question to anyone who uses CONNECT TO EMAIL action
so each user, at login, connects to their mailbox for regular polling?
Any server processes the read emails?
Any server processes the read emails?
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.
Jaymer
Aware Programming & Consulting - Tampa FL
Jaymer
Aware Programming & Consulting - Tampa FL
Re: a question to anyone who uses CONNECT TO EMAIL action
Our scenario is a bit different.
We read email from a single "support" mailbox to convert emails to support cases.
The reason we put it in the VP init is probably because the scheduler didn't work out for us.
The user login will trigger the email connection if, for instance, a new version has been published or if the the mail connection fails for some reason.
Yes, we store the incoming emails in a regular BO that looks similar to the attributes found in the IncomingEmail notification object.
We simply use a CREATE action in Rules(received) in the IncomingEmail notififcation object:
InkommandeEmail contains update rules with what we call "mail washing", like removing html, css, redudant space characters, redudant newlines, etc.
But we also store the original email body in case the mail washing produces strange results.
This is a thread about the "washing" part:
viewtopic.php?f=1&t=12031&p=55803&hilit ... ail#p55803
We read email from a single "support" mailbox to convert emails to support cases.
The reason we put it in the VP init is probably because the scheduler didn't work out for us.
The user login will trigger the email connection if, for instance, a new version has been published or if the the mail connection fails for some reason.
Yes, we store the incoming emails in a regular BO that looks similar to the attributes found in the IncomingEmail notification object.
We simply use a CREATE action in Rules(received) in the IncomingEmail notififcation object:
Code: Select all
CREATE InkommandeMail WITH
InkommandeMail.Subject=IncomingEmail.Subject,
InkommandeMail.Message=IncomingEmail.Message,
InkommandeMail.FromAddress=IncomingEmail.FromAddress,
InkommandeMail.ToAddress=IncomingEmail.ToAddress,
InkommandeMail.SentDate=IncomingEmail.SentDate
But we also store the original email body in case the mail washing produces strange results.
This is a thread about the "washing" part:
viewtopic.php?f=1&t=12031&p=55803&hilit ... ail#p55803