The Mit's Blog

"Plutôt que sortir votre VS.Net le Nabaztag qui suit (demandé à Phil, il expliquera smile_tongue)..."

Plutôt que de longues explications : http://www.woodwardweb.com/gadgets/000434.html

:)

Personnellement, je déconseille ouvertement SPD pour les créations de WorkFlow.

Ce produit ne doit être utilisé que dans le cadre de modélisation, maketage, simulation, ...

Mais surtout jamais de production.

En effet, le cas classique est celui ou le WF créé avec SPD fonctionne un moment et habitue les utilisateurs, puis d'un coup sans raison tout s'arrête. Aucun message d'erreur nulle part, aucune raison particulière, mais tout est bien stoppé.

- Exemple : http://forums.microsoft.com/MSDN-FR/ShowPost.aspx?PostID=3708296&SiteID=12

La seule solution est de tout supprimer et tout recréer, mais des questions se posent alors :

- Comment expliquer aux utilisateurs qu'ils ont perdu toutes les étapes en cours ?

- Comment dire à ces mêmes utilisateurs que la solution développée peut casser à tout moment ?

- Comment ne pas dégrader l'image de la plateforme SharePoint à cause de la fiabilité pitoyable de ce produit ?

Bref, il faut vraiment réfléchir à cela avant de se lancer dans ce type d'aventure et de s'y casser les dents.

Romelard Fabrice [MVP]

Plus sérieusement, je suis pas fan non plus de l'utilisation de SPD pour les workflows pour les mêmes raisons que fabrice.

C'est pratique pour des POC par contre.

Pour appuyer mon avis, nous avons eu une ferme SharePoint (Ferme WSS V3 des US avec plus de 10 000 Users) qui s'est mise a partir en vrille d'un coup (sans aucune raison) à cause de WF SPD avec Custom Activities alors que tout marchait bien peu avant.

La solution avant de totalement supprimer ce WF était de faire un IISRESET de cette ferme toutes les 30 à 60 min, car on avait un Error 500 qui apparaissait.

Donc ce n'est vraiment pas parce que je suis fan de VS, mais réellement parce que le résultat des WF sous SPD est réellement "sal" et sans aucun contrôle.

Romelard Fabrice [MVP]

A mon sens le XOML généré par VS et celui de SPD doivent différer.

De plus ce XOML de SPD n'est pas généré réellement dans des fichiers physiques, mais se voit directement stockés en DB (au niveau de la collection de site, ce qui explique en partie pourquoi un WF de SPD est spécifique à un site et une collection).

Lorsqu'on ouvre un XOML de SPD et qu'on le compare avec celui d'un VS, les grandes différences qui sautent aux yeux :

- Bloc XML de départ différents "RootWorkflowActivityWithData" pour SPD, "SequentialWorkflowActivity" dans les WF Sequentiels de VS

- Pas de possibilité de mettre de code C# dans les WF SPD, donc pas d'utilisation des MethodInvoking="xxxxx" pour les composant VS

- Fixation en dur des GUID des listes SharePoint utiliées pour le WF SPD <ns0:LookupActivity ListId="{}{E81BF4FB-E5FA-4DBB-9315-B63E7ADC5315}" ....

Bref à voir si en changeant ces premiers points on arrive à s'en sortir, mais je me demande si ca ne risque pas de faire perdre plus de temps que d'en gagner.

Romelard Fabrice [MVP]

C'est vrai qu'il est possible de migrer le WF fait avec SPD vers VS mais il n'existe pas de guideline officielles à ce sujet à ce sujet.

Et pour l'avoir fait de nombreuses fois, sans être difficiles, ce n'est pas très friendly...

Mon plus gros problème est justement le déploiement : Effectivement il est très simple de déployer un WF via SPD mais que ce passe t il dès qu'on veut utiliser le même WF sur une autre liste/site/etc...

J'ai un facheuse tendance à limiter l'utilisation de SPD en environnement de développement pour Masterpage, Layout voire cas extrème WF (quand ils sont ultra simples) pour après exporter le tout dans une solution (WSP) proprement par la suite.

Mais bon je sais qu'on fait tous pareil :)

Autre solution...

On sort tous notre portefeuille et on achète des licences K2 BlackPoint .. :D :D :D

Un vrai moteur de WF :) N'importe quel End-User ayant un minimum de connaissance des processus métiers peut modéliser son WF.

http://blackpoint.k2.com/en/index.aspx

Amicalement,

Il existe d'autres produits tiers permettant de créer des WF dans SharePoint, certains plus ou moins intégrés :

- NINTEX (parfaitement intégré à SharePoint 2007)

- WorkFlow Gen (permettant de travailler avec des interfaces 2003 ou 2007 ou même sans SharePoint)

Donc, il n'existe pas que K2 :)

Fabrice

Certes, et dans la foulé, il existe aussi Skelta :)

Pour moi Nintex n'est pas parfaitement intégré à Sharepoint. Dés que tu veux avoir des activités qui utilisent les résultats du service de recherche, "out of the box" c'est impossible. Il manque aussi des connecteurs comme celui à SAP de K2. D'autre part, le déploiement d'une solution Nintex ne peut s'affecter à un content type particulier dans Sharepoint.

Je dis ça sans avoir d'action à K2 :p .. si si !

David

Bonjour,

Je me permets de donner mon avis sur SPD.

Nous avons récemment lancé un workflow, selon moi peu complexe, mais qui nécessitait des évolutions facilement réalisables par des personnes "non expérimentés", d'où l'utilisation de SPD.

Le prototype s'est bien déroulé mais depuis la mise en production, nous nous sommes rendus à l’évidence: SPD ne tient pas du tout la charge.

Certains Workflows tombent en erreur sans raison apparente, et beaucoup de nos tâches restent éternellement verrouillés. (Après l’ouverture d’un case ms support, il s’est avéré que ces tâches verrouillées sont une conséquence des erreurs de workflow, non résolues à ce jour). Un expert Microsoft a analysé notre workflow et nous a confirmé qu'il était dans les bonnes pratiques, à l’exception de notre bibliothèque de documents qui contient les Workflows qui excède les 2000 éléments (4000 dans notre cas).

Bref, cette expérience nous donne une mauvaise image du produit, qui selon moi, possède de très gros atouts.