|
Team Foundation Server – Eventing Service - Part 2 (Publishing events)
|
|
Rating: 4 user(s) have rated this article
Posted by: Subodh Sohoni,
on 4/16/2008,
in category "VSTS"
Views: this article has been read 5804 times
Abstract: In the first part of this article we discussed about how to subscribe to the events which are published by the Team Foundation Server (TFS). Although the events published by TFS are quite extensive, there still may exist need to subscribe to the events which are not covered by TFS. To publish such events we need to create a separate event class and an application to raise that event.
Team Foundation Server – Eventing Service - Part 2 (Publishing events)
In the first part of this article we discussed about how to subscribe to the events which are published by the Team Foundation Server (TFS). Although the events published by TFS are quite extensive, there still may exist need to subscribe to the events which are not covered by TFS. To publish such events we need to create a separate event class and an application to raise that event.
This article discusses:
- How to publish an event which can be subscribed to
- How to raise that event from an application with certain event related data
- How to access the event related data
Publishing events
Events which are to be published are loosely coupled with the subscribers. The responsibility of notification of the event being raised is with the TFS. The notification service of TFS needs the .xsd file representing the event class to be present at a specific location in the file system. We begin creating that file by first creating a class library which contains the class which represents the event. This class has certain restrictions
1. It should have a default public constructor, a constructor that does not accept any parameter.
2. It also will have public fields which will be assigned values during raising the event.
3. The class should be serializable i.e. should have Serializable attribute.
The example of such a class is given below:
C#
using System;
using System.Collections.Generic;
using System.Text;
namespace WorkItemAddedEvent
{
[Serializable]
public class WorkItemAddedEventType
{
public WorkItemAddedEventType()
{ }
public string id;
public string projectUri;
}
}
VB.NET
Imports System
Imports System.Collections.Generic
Imports System.Text
Namespace WorkItemAddedEvent
<Serializable> _
Public Class WorkItemAddedEventType
Public Sub New()
End Sub
Public id As String
Public projectUri As String
End Class
End Namespace
Once the class is compiled into a component and a .dll is created, we can use the tool XSD.exe to convert the class to the respective .xsd file. The syntax of the command is as follows:
>XSD.exe MyComponent.dll /type:WorkItemAddedEventType /out:DirName
This command generates the schema file representing the event class. The generated schema file for the above written class would look like this:
<?xml version="1.0"encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="WorkItemAddedEventType" nillable="true" type="WorkItemAddedEventType" />
<xs:complexType name="WorkItemAddedEventType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="id" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="1" name="projectUri" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>
This generated XSD file is stored at …\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\v1.0\Transforms with the same name as the class name which in this case would result in to a file named WorkItemAddedEventType.xsd.
Once the file has been stored at the mentioned location, notification service of TFS will come to know about it after IIS is restarted. Execute the >iisreset.exe command to do that. Now anyone can subscribe to this event.
Raising the published events
The event that is published can now be raised using the Team Foundation Object Model. We can create a component or a windows desktop application to raise the event. In that application we need to give the reference to following dlls:
1. Microsoft.TeamFoundation.dll
2. Microsoft.TeamFoundation.Client.dll
3. The dll which contains the event class.
4. Any additional service which we are using for example in this example since we are adding a workitem, we need to give reference to Microsoft.TeamFoundation.WorkItemTracking.Client.dll
We will need now to create an instance of IEventService and call the FireAsyncEvent method of that instance to start the notification to the subscribers. The code to do that is in the listing below:
C#
TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("http://SEED_tfs:8080");
IEventService EventService = (IEventService)tfs.GetService(typeof(IEventService));
WorkItemAddedEventType WIAddedEv = new WorkItemAddedEventType();
WIAddedEv.id = wi.Id.ToString();
//wi is the instance of new workitem being added
WIAddedEv.projectUri = proj; // proj is the name of the team project
EventService.FireAsyncEvent(WIAddedEv);
The fields which are given values here can be accessed using the template as was given in the Part 1 of this article. The template which will be used to create the email may look like this:
<html>
<head>
<title>TFS Workitem Tracking Subsystem Notification</title>
</head>
<body style="font-family:courier new; font-size:12px;">
<div>WorkItem has been added</div>
<br />
<div>
WorkItem ID: <variable name="id" />
</div>
<divTeam Project:=""
<variable name="projectUri" />
</div>
</body>
</html>
In this format the variable tag extracts the data from the event arguments and displays it.
Conclusion
In this article we have seen how to write your own events, how to publish them and how to raise the events which will be notified to the subscribers. This mechanism provides excellent way to extending the functionality for automation of tasks involved with TFS.
I hope this article was useful and I thank you for viewing it.