I have a plugin written that is registered for the DeliverIncoming message on the email entity in CRM. The plugin fires normally when emails arrive into a queue.
I also have a console application that connects to the CRM service, checks the followupby attribute of cases and depending on the date sends out a reminder/overdue notification.
The problem is that these emails aren't causing the plugin to fire. The email activities are created in CRM and the emails are sent and delivered without any issue but the plugin doesn't fire. I also tried registering the plugin against the Create message of the email entity and that doesn't fire either.
The emails are sent using the SendEmailFromTemplateRequest as the request object being passed into the CrmService.Execute() method
The plugin fires for all other instances of emails being delivered. The emails sent from the console application are the only ones experiencing this issue. Does anybody know why this would occur?
Thanks,
Neil
DeliverIncoming only fires for eMails routed into the CRM queues by the eMail Router. It will not fire on eMails you send from the CRM system.
Finding out what exact message a plugin needs to be registered against to fire on a certain action is sometimes a case of trial and error. Write a simple plugin that just logs the time and context.MessageName somewhere and register it against any message valid for the email entity. Then send an eMail through your application and have a look at what the plugin logged.
Turns out the plugin was firing, but when run from the console application it was throwing an exception when trying to log to a file it didn't have permission to. I had a break point on the second line, the first line was the logging line.
Related
I have a Microsoft Dynamics CRM 2011 deployment that has workflows that send e-mails to users. The e-mails were being sent as normal before but they suddenly stopped working.
If I manually create an e-mail entity or trigger a workflow by hand the mails are sent as expected. However when they are automatically triggered the status of the e-mail is still marked as sent but they are not sent to user.
I tried restarting the e-mail router to no avail.
When a background workflow is triggered, it will run as the owner of the workflow. When it is manually triggered, it will run as the user who manually triggered it.
Check to make sure the owner of the workflow has correct email router settings. You could also assign the workflow to yourself since you know your email settings are working.
I'm trying to send the mail to the store (Node), on the onsucess event of createOrder api.
So for this, I've created 2 new services.
The first service receives the information from the onsucess event of the createOrder api and passes it on to the queue.
The second service receives the information from that queue and passes it on to the email server.
This sends the email. The problem is that for some of the orders the email is not sending, but we are not getting any exceptions for these.
In the logs for those orders it shows the "Successful Acknowledgement from the email server".
I don't know where the exact problem is. I have checked the email server, but cannot find anything related to the missing order information.
What steps can I take to further debug this problem?
You are saying, only some orders have this problem . Then it will be something related with the order details like the email id associated with it. And also if the successful message in logs shows message has been sent. But if it is a customized log please check it once again. If its Ok then please check the Email Server logs directly.
I am facing one issue, when I send a mail through Subscription in SSRS, it will send the mail twice or thrice. So for a time being I have stop the Reporting services. And when I again open that service mail sent automatically.
Please suggest...
i have email event listner like, but the emails are not sending, please help me on this
and my exception handling code is
First check that you can send emails via your configured email server from the installation computer, Microsoft KB153119 will tell you how to do this.
Second check it is the email listener that is failing. Remove all but the email listener and try again. It removing the Event log listener helps then the application might not have sufficient rights to create the event log source (this should be done by the installer).
Third check the exception that would trigger an email is being raised, either step through code or swap the email listener to a text file listener.
Finally, as Ashwani says, provide a little of your code and config for us to look at.
I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:
Register for an account by filling out a form and submitting it.
Receive an email with a confirmation code link
Click the link to confirm the new account and log in
When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:
A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.
How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.
We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.
TRANSACTIONAL & SYNCHRONOUS
The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.
TRANSACTIONAL & ASYNCHRONOUS
The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.
The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.
NON-TRANSACTIONAL & SYNCHRONOUS
The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout
When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.
NON-TRANSACTIONAL & ASYNCHRONOUS
The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.
What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!
The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.
My 2 cents:
Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.
In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.
What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.
Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.