Team System events notification services
Cela fait un moment que je n'ai pas blogué, beaucoup de travail (une préparation de site 100% AtlasToolKits, l'ajout de contenu sur Workflow Foundation et 3 mois à plein temps sur Team System!), mais, tandis que
certains se la coulent douce, me revoilà :)
Ce matin, j'ai voulu préparer une toute petite démonstration sur l'events notification services de Team Foundation server ou j'ai misérablement perdu une heure sur une erreur stupide!
Mais qu'est ce que l'events notification services?
Ce service permet, via un exécutable fournit avec TFS, de s'abonner à des événements lancés par Team System: Checkin, ajout/modification d'un WorkItem, Compilation, création de projets...
Les évènements suivant sont fournis en standard:
- AclChangedEvent
- BranchMovedEvent
- BuildCompletionEvent
- BuildStatusChangeEvent
- CheckinEvent
- CommonStructureChangedEvent
- DataChangedEvent
- IdentityCreatedEvent
- IdentityDeletedEvent
- MembershipChangedEvent
- NodeCreatedEvent
- NodePropertiesChangedEvent
- NodeRenamedEvent
- NodesDeletedEvent
- ProjectCreatedEvent
- ProjectDeletedEvent
- WorkItemChangedEvent
Deux types d'abonnement sont possibles :
- Le premier, banal, en spécifiant une adresse Email qui recevra une alerte à chaque levée d'événement
- Le deuxième, plus intéressant, en spécifiant l’ URL d'un Web service (SOAP) qui sera appelé et qui effectuera l'action que vous désirez (et pourquoi pas le déclenchement d'un workflow?)
Au niveau du fonctionnement, l'exécutable qui permet de s'abonner aux événements se nomme BisSubscribe.exe et se situe dans le répertoire "C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup"
Sa syntaxe de fonctionnement est la suivante pour la RTM de TFS (petite modification par rapport à la version précédante)
Usage:
BisSubscribe /eventType <eventType> /address <emailOrSoapAddress>
[/deliveryType EmailHtml|EmailPlaintext|Soap] [/server <servername>]
[/filter <filterString>][/tag <tag>]
BisSubscribe /unsubscribe /id <id> [/server <servername>]
where:
eventType: The name of the event. Case sensitive.
filter: (default none) A filter expression.
address: The email address or webmethod URL for the subscriber.
server: The Team Foundation Server name.
tag: (default none) A field to later use to identify this subscription.
deliveryType: (default Soap) EmailHtml|EmailPlaintext|Soap indicating the preferred format.
id: The integer id for the subscription to be deleted when unsubscribing.
Donc par exemple, pour souscrire à une modification de WorkItem via Email:
BisSubscribe.exe /eventType WorkItemChangedEvent /address toto@toto.org /deliveryType EmailHtml /server TF-WK
Ou pour déclencher un Web Service lors d'un checkIn:
BisSubscribe.exe /eventType CheckinEvent /address http://localhost:8080/Test/WebService.asmx /deliveryType Soap /server TF-WK
ou WebService.asmx ressemblera par exemple à ceci:
Imports System.Web
Imports System.Web.Services
Imports System.Web.Services.Protocols
<WebService(Namespace:="http://tempuri.org/")> _
<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _
Public Class WebService
Inherits System.Web.Services.WebService
<SoapDocumentMethod(Action:="http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", RequestNamespace:="http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03"), WebMethod()> _
Public Sub Notify(ByVal eventXml As String)
Dim sFileName As String = "c:\test.xml"
Dim fs As New System.IO.FileStream(sFileName, IO.FileMode.OpenOrCreate, IO.FileAccess.Write)
Dim sw As New System.IO.StreamWriter(fs)
sw.WriteLine(eventXml)
sw.WriteLine(Now)
sw.Flush()
sw.Close()
fs.Close()
End Sub
End Class
Si vous voulez éviter de perdre une heure comme moi, c'est donc ici qu'il faut faire attention, au niveau des schémas, de bien spécifier "[...]/Notification/03/Notify" et non "[...]/Notification/02/Notify" comme dans les versions pré-RTM.
La chaine de caractères eventXML contiendra toute les informations relatives au contexte de déclenchement de l'évènement, vous pouvez donc imaginer n'importe quel type de traitement de ces informations (par exemple créer et assigner un workItem pour notifier un testeur qu'une compilation a eut lieu et qu'il faut qu'il vérifie les logs des tests unitaires)
Il est possible, avec BisSuscribe.exe d'affiner avec des filtres le déclenchement d'événements, par exemple déclencher un événement uniquement sur la modification de WorkItems de type "bug".
Voila, have fun :)
