(Incidentally this was a question that I got in my interview loop)
One of the components of Team Foundation Server is a Notification Service. The MSDN doc describes it like this:
The Team Foundation Notification Service is a reliable, asynchronous publish-and-subscribe event-notification system that supports the distributed Visual Studio Team System environment. The notification service enables a tool or service to register event types. Users can subscribe to those events. Other services may subscribe to the events as well. When the source tool raises an event, it matches the event with subscriptions and notifications.
You can make a notification in the following way:
Notify an end-user through e-mail.
Identify the invocation of a Web service.
The question is regarding the second bullet point above: “Does TFS guarantee delivery of notifications to web service endpoints?”.
The TFS system will retry every two hours for 6 retries. Delivery is not guaranteed despite the retries because the “firing” of the event is not transactional with the action that causes the event. i.e.
- User saves a work item change to the Work Item Tracking database.
- Work Item Tracking “fires” an event that stores the event in the Integration database.
- Eventing service notifies subscribers (with retries).
If the application crashes between the persistence to the Work Item Tracking database and the persistence to the Integration database, the event is permanently lost.
So in theory, if you are building an application that relies on these events, you’ll also need to establish a mechanism that reconciles any events that might have been missed. For example, if you’re subscribing to the WorkItemChanged event to sync two work item repositories, then you’ll need to run a query that does something like “What’s the Last Changed Date for each work item – do they match?”.
Brian Randell’s Team Foundation Server Event Service article for MSDN Magazine has good examples for writing your own web service endpoint and subscribing to TFS events.