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?
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.
so each user, at login, connects to their mailbox for regular polling?
Any server processes the read emails?
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:
CREATE InkommandeMail WITH
InkommandeMail.Subject=IncomingEmail.Subject,
InkommandeMail.Message=IncomingEmail.Message,
InkommandeMail.FromAddress=IncomingEmail.FromAddress,
InkommandeMail.ToAddress=IncomingEmail.ToAddress,
InkommandeMail.SentDate=IncomingEmail.SentDate
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:
"washing" IncomingEmail.Message contents to make it readable (comment)&hilit=incomingemail#p55803