I am using Exchange web services (Exchange server 2010) to synchronize user's outlook calendar with my application.I implemented EWS Push Notifications to call back my application whenever events are created ,modified ,deleted by out look users. I achieved this by subscribing user's email credentials with EWS.
Client application should send OK responses to server whenever it get callbacks from the server .If there are no OK responses from client application for some time the particular subscription will be automatically unsubscribed.
If client is unreachable for some time due to any unexpected reason i need to subscribe only unsubscribed users instead of subscribing all the users.
My issue now is how to get unsubscribed users/Or subscriptions Id's from EWS?I couldn't find anything helpful regarding this in MSDN documentation.
Any one knows?
MSDN Reference
enter link description here
I believe the only way to do this is to make use of the StatusEvent
(I call it the heartbeat). When you subscribe, you set a parameter to indicate how often EWS is to POST to your Push HTTP listener. (I use 3 minutes--YMMV.) So after 3 minutes (plus a little extra to be sure), if you don't hear from EWS, either by a StatusEvent or some other "real" event for a subscription, then you should re-subscribe for that user.
Related
Problem
Currently, our website is setup so that when an action is taken that requires an email to be sent, our website will make a call the the SMTP server to attempt to send an email. The problem lies when the SMTP server goes down for whatever reason. We don't store any outgoing emails in any fashion so if the email to be sent fails, it's is lost forever (not really as it can easily be regenerated, but we don't have a mechanics to let us know it failed, except Azure Application Insights). While we also have the website send the devs an email when exceptions occur, for obvious reasons, we will not receive those emails.
Goal
Our goals is to stop having our website send an email directly to the email relay server. Instead, implement a solution that would send emails and have the ability to recover should a problem occur.
Stop the website from sending the emails
Ability to recover from transient or side issues/exceptions
Log as much activity as possible concerning the email (send attempts/fails/etc)
Ability to recover the activity logs from potential transient or side issues/exceptions
Ability to re-trigger a email to be sent if ever necessary (optional)
Solution
I read a 3-part article that sounds like it would solve this issue and I'm currently developing it.
I'm building a process using Microsoft.Azure.ServiceBus Topics and Subscriptions to manage sending emails from our website. I've gone through many samples and have been successfully able to SendAsync() a Message, ReceiveAsync() a Message, and CompleteAsync() or AbandonAsync() it appropriately.
Side-note: I'm now exploring how to work with the RetryPolicy to see if this will help me defer a retry to a bit of a longer period, though I'm not sure if I can/should use it for that.
While most of the process has been built so far, so I can understand the underlying infrastructure, I'm also still within the planning phase to make sure we plan appropriately.
We are currently trying to figure out the best or most appropriate workflow for this process. We figured two Topics would be needed: one for the emails to be sent EmailTopic, and one for the logs to record LogTopic.
The reason for the LogTopic is to handle any transient issues when attempting to save a log activity to the database. For example: I successfully retrieve an email to be sent. I then attempt the send the email and log this attempt. The email gets sent successfully. I then try to log this activity, but the database just went down and I'd would not be able to log this activity. The second Topic should alleviate that, but what happens if that goes down?
Here's our current workflow:
Website inserts data into a database that defines the email to be sent (currently, we'll have a field for the Body which will be the email contents itself, another table to hold the Email Templates which will contain the contents around the Body field, along with from, to, CC, BCC, and file attachments)
Website sends a small Message to the EmailTopic with the MessageId of the inserted record
A Stateless Service Fabric Service listens for messages
Receive the Message, get all details from the database for the record
Build the SMTPClient and attempt to send the email to the SMTP server
Send a Message to the LogTopic with the MessageId, current date, current DeliveryCount, and action taken (attempt to send email)
If successful, CompleteAsync() the Message and send a Message to the LogTopic with the MessageId, current date, current DeliveryCount, and action taken: "email sent"
If unsuccessful, AbandonAsync() the Message and send a Message to the LogTopic with the MessageId, current date, current DeliveryCount, and action taken: "email failed to send" (after 10 attempts message would automatically be placed in the DeadLetterQueue
In this workflow, the LogTopic will contain all the actions taken and will be stored in the database when the message(es) is(are) received. Obviously, if messages are abandoned for any reason and sent the the DeadLetterQueue, we will have a process to try to insert them at a later point.
Questions
We thought about just storing logs to the database within the workflow, but the question "what if the db goes down in the meantime?" (hence when Azure Central US went down last week) came up so we decided to use this 2nd Topic. Obviously, if the Service Bus is down, we can't send this message and I don't know how to recover from that, except log ETWs and check them some other way. Should I be attempting a DB save first, and if that fails, send a Message to the Topic?
Are there too many things going on in this service and should I split some operations around?
Is there a flaws or missing items in the workflow itself that we aren't taking into consideration?
Should we be using 1 Topic and add a Label to the message so we know it's a log vs email to be sent? Maybe using filters (not sure how to properly do this or if it's appropriate for this workflow yet)?
Are we asking too many questions in this 1 SO post and should split each question apart?
I think the work flow can be improved in such a way that the failures can be tracked and resolvable. I am providing my solution in achieving this.
Service Bus Topics supports multiple subscribers for single sender. This is achievable with the help of Subscriptions.
Instead of sending the message to two Topics, You can create two Subscriptions under a Topic. Refer here for filtering messages into Subscriptions using Rules.
You can create different Rules for the Subscriptions. Once the message is sent to a Topic, the custom properties of the message gets validated against the Rules of each Subscription. Based on the result of the validation, the message will get into the Subscription which has the required Rule condition.
Lets say the Subscriptions created are Email and Log. The Stateless Service Fabric Service should listen for the messages form both these Subscriptions.
Website should send the message to the Topic with the custom properties for Email Subscription.
Whenever a message is received by the Stateless Service Fabric Service, it should start a thread to send the mail.
Once the email is sent successfully, a Success message should be sent to the Topic with the custom properties for Log Subscription. In case of failure in sending mail, the message in Email Subscription should be dead lettered and a Failure message should be sent to the Topic with appropriate custom properties for Log Subscription.
The Stateless Service Fabric Service which listens also for the messages from Log Subscription will create a thread to write to the database as and when a message is arrived. In case of failure in writing into database, the message in Log Subscription should be dead lettered.
You can monitor the count of the dead letter messages of both the Subscriptions to ensure there is no failure. If the count is greater than 0, there should be manual intervention in Resubmitting the dead letter messages to the Topic. There are may tools available in market to monitor and resubmit the dead letter messages or you can also develop a custom application for doing that.
I guess this workflow should work as expected. Once this is installed, the only thing that need to be taken care is the dead letter messages in both the Subscriptions.
I need help in implementing a program using C# that gets notified by Exchange Server every time a new message is received by a certain mailbox , the C# program needs to collect some information from the mail received and save those infos in a SQL-Server Database .Please provide me any infos , or links/ code sample to implement this , any advices on how to achieve this would be appreciated .
For getting notifications, you can subscribe to the mailbox folders. That way you can get notification every time you receive an email and there are various event types to subscribe to.
This is the link you can follow for the notification purpose:
https://msdn.microsoft.com/en-us/library/office/dn458792(v=exchg.150).aspx
Mostly its better to get the notifications from the resources as the logged in user has permissions to the resources. You have to log in as the same user if you want the access to that specific mailbox folder.
I believe the EventType.Created event will give you access to the notification where any incoming message will push out the notification.
I try to register a handler for incoming calls for all Lync Users. The problem is I cannot store all the Credentials that are needed when using a UserEndpoint. At the moment I have managed to retrieve all Lync Users and also their online state with a hard coded service UserEndpoint.
As I already figured out, you cannot listen for incoming calls with an ApplicationEndpoint, so do I need a UserEndpoint for every Lync User? I read somewhere that it is possible to create a UserEndpoint without Credentials in a trusted Application.
In theory I already created a trusted application relationship between the Lync Front End Server and the Application Server and also registered the TrustedApplicationEndpoint. I just can't be sure if it is really working as I do not get a different result when changing the trustedapplicationname or any of the other settings.
Is there another way to solve this problem?
If not what do I have to do to listen for all incoming Calls?
You can listen to register for incoming calls on an ApplicationEndpoint, but it will listen only to calls directed to it, not to other users. An application endpoint has it's own SIP address.
You can deal with your problems in multiple ways. A lot depends on what you want to do with "listening to all incoming calls".
The route you have chosen is to create a UserEndpoint for each user. If you have a trusted application already set up, you can use its CollaborationPlatform to create new user endpoints. The idea of a "trusted" application is that it is allowed to impersonate everyone and create endpoints on their behalf, without having each users' credentials.
Some important things to think about for this solution:
Creating an endpoint for every user could mean creating and managing a lot of endpoints.
Users will be shown as online (or away/busy/etc) whether they really are or not, because you created an active endpoint for them.
This will not catch calls to non-existing addresses (might not be a real problem).
The second option is to use MSPL to change the routing of incoming calls. You can redirect calls to the SIP address of your ApplicationEndpoint, and you will need only 1 endpoint and one call listener. Some more info and details on this method can be found here: Rerouting requests to a UCMA application with MSPL.
As said before, a lot depends on what you're trying to achieve here.
We are currently trying to implement workflow functionality in our product (.NET 4.5). For this we consider using Microsoft Workflow Foundation 4.5. However in this early stage we bumped into a technical problem of something that seems very doable.
Simply put this is what we want to achieve in our client/server setup:
Based on a specific event the server starts a workflow
The workflow executes some actions until it comes to an activity that requires human interaction. It should then wait for a message from a client.
One client (there are multiple clients) becomes the owner and therefore should send its unique id or address to the workflow
The workflow sends a message to that client indicating that it requires information to continue (e.g. e-mail parameters like recipient, subject and body)
After several minutes (could be a few minutes to a few hours) the client sends the information to the workflow so that it can continue (e.g. send the e-mail message)
If another human interaction is required, the server sends a request message to the client again so that it knows it should ask the user for information and then the client sends a message to the workflow again (like above)
For what I understood a 'normal' workflow does not have an endpoint to receive messages. A workflow service on the other hand does, but with WF services the workflow instances would be created based on the incoming requests rather than having the server be in control of the creation of workflows (right?).
At this moment it appears to me that we need a combination of a workflow and a workflow service.
I've been struggling with this for a while now and searched high and low but cannot find useful information about it.
I think we have two options:
Workflow services;
If we would use workflow services, we could have a Receive activity at the beginning of the workflow that starts the workflow. However, then how can clients communicatate with that specific workflow? A workflow service has one specific URL.
Workflows;
A normal workflow that is hosted by a server application seems the most natural path to choose. However, then we need a way to send data to it. So, is it possible to upgrade a normal workflow so that the Receive activity can be used? And if so, how? And how do messages end up in the right workflow instance?
My questions are:
Does anybody have some useful guidance or information on how to solve the above problem?
Are there interesting alternatives (not using WF?) to accomplish this?
Does anybody have documentation about how WCF messages are routed to the correct workflow instance in WF?
PS: We have a WCF service available on the client. A workflow can communicate with that. For short running requests that isn't a problem, but the thing is that requests can take a long time before the client 'answers' them. Also, the client can only request the information if the user clicks on a continue button (the users should not get a popup just in the middle of something because the server wants information)
Yes, the Workflow Service with AppFabric is ideal and should just work out of the box if I understand your problem correctly.
For your question "However, then how can clients communicatate with that specific workflow?" the answer is correlation and you can easily set that up in the first Receive. You just add a CorrelationHandle variable and set the Receive's CorrelatesOn for an incoming parameter (ownerid?) and CorrelatesWith to that handle. Do the same for all other receives and the incoming messages will always be routed to the right instance.
AppFabric will help in that your WF service will be unloaded from memory and persisted when it's idle for too long, woken up when the new receive comes and etc. It will also help in that you can set autostart on your IIS app pool. WAS will activate your workflow service on incoming request.
If you need further specific details just let me know.
I would like to address such a issue: I have a HTML form (like register form) which submission sends email. Now I send it as a part of page request. Obvious drawbacks:
makes request longer
sometimes smtp server is down, or timeouts and emails are not sent
When working with PHP I used a solution that based on queue - I had been putting an object/xml to queue host, and then some kind of client checked that queue. If queue task was sucessfully handled it removed task from queue. I wonder, is there a similar implementation on Windows / .NET platform ?
Thanks,Paweł
There is robust queuing offered by MSMQ which is easy to use in .NET. Accessing Message Queues might be a good place to start.
AH - why?
I have a HTML form (like register form) which submission sends email.
Have the submission write the email to a local drop directory, then use the SMTP service of the Windows system to submit them to your providers email server. Alternatively use your own service to copy them to the outgoing email pickup folder (I do that so I can put in a code pointing to the website for tracking).
These are provided standard methods.
You don't neccessarily need a queue as such. You can use the SendAsync method on the System.Net.Mail.SmtpClient class. That will return immediately and not block the page.
See: http://msdn.microsoft.com/en-us/library/x5x13z6h.aspx