Dans la première partie, nous avons vu comment régler le problème des Workflows SharePoint qui ne sont pas déclenchés depuis Master Data Services 2012 (re sic, mais ça vous l’avez vu dans le premier Post)

Dans ce deuxième post, je vais m’attacher à vous expliquer comment créer un WorkFlow dans SharePoint, le lancer depuis MDS, et surtout, pouvoir le débuguer Sourire

Vous trouverez les sources à la fin du Post.

 

Le Workflow a créer est relativement simple :

Nous avons un produit dans notre solution de MDM, et lorsque ce produit est créé, un WorkFlow est déclenché coté SharePoint pour valider la création de ce produit

Il passe donc par plusieurs états :

Nouveau –> Validé par le Service achat –> Validé par le service Production

A chaque phase de validation, un Rejet peut avoir lieu.

Chaque phase de validation va générer une tache pour chaque responsable de service.

Je suis en phase de développement il est donc important de pouvoir débuguer le tout !

 

La solution

Pour ce faire, je vais créer deux projets Visual Studio:

  1. Le premier projet contient l’Extender SharePoint MDS appelé par le service Windows MDS
  2. Le deuxième projet contient le projet SharePoint Workflow hébergé dans SharePoint

image

Le projet Extender Sharepoint Workflow

L’idée ici c’est de lancer le service Windows MDS en mode debug. Pour ce faire c’est tout simple, il suffit de lancer l’exe avec l’argument –console. Il suffit donc de paramétrer le projet pour lancer cet exécutable :

Pour rappel, chez moi c’est « C:\Program Files\Microsoft SQL Server\110\Master Data Services\WebApplication\bin\Microsoft.MasterDataServices.Workflow.exe »

image

Lorsque le service est lancé il charge les extenders définis dans son web.config (Microsoft.MasterDataServices.Workflow.exe.config).

Il faut donc le modifier en conséquence pour qu’il charge notre extender.

Voici le fichier config modifié :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        bla bla bla ...        
    </configSections>
    <applicationSettings>
        <Microsoft.MasterDataServices.Workflow.Properties.Settings>
            <setting name="ConnectionString" serializeAs="String">
                <value>Server=.\POWERPIVOT;Database=MDS;Integrated Security=true</value>
            </setting>
            <setting name="WorkflowTypeExtenders" serializeAs="String">
                <value>SPWF=SharePoint.WorkflowExtender.SharePointWorkflowExtender, 
                       SharePoint.WorkflowExtender
                </value>
            </setting>
        </Microsoft.MasterDataServices.Workflow.Properties.Settings>
    </applicationSettings>
</configuration>

 

Les extenders doivent être soit dans le GAC, soit dans le répertoire. En mode Debug, on va juste déployer directement dans le répertoire du service MDS.

Pour rappel, chez moi il se situe sur “C:\Program Files\Microsoft SQL Server\110\Master Data Services\WebApplication\bin

image

A partir de là, notre Service MDS est capable non seulement de lancer un Workflow SharePoint mais en plus on peut débuguer notre Extender (au cas où, on sait jamais Sourire)

Au lancement de notre projet, on a bien le chargement de notre extender :

image

Ok, Next step configuration de MDS et création du Workflow.

 

Configuration Master Data Services 2012

 

Ici dans l’idée, je pars du principe que vous connaissez un tantinet MDS et que vous avez par exemple charger un référentiel (Produit ou autre, peu importe)

Nous allons :

  • Créer une entité ApprovalStatus qui contiendra les attributs classiques (Nom, Code)
  • Créer les membres de cette entité correspondant aux états d’approbation:
    • Nouveau
    • En cours d’approbation
    • Approuvé
    • Rejeté

image

 

Alors certains diront que oui, on peut demander à ce que l’état en cours d’approbation soit délayé en deux états  ( En cours d’approbation au service achat et En cours d’approbation au service production).

Le débat est ouvert concernant ce point particulier, mais de mon point de vue, un MDM ne doit pas géré un état intermédiaire. Il est là pour dire si une donnée est validée… ou pas.

Ces états, c’est à SharePoint qu’en revient la responsabilité.

Bref, il suffit ensuite d’appliquer cette entité comme Attribut de notre produit et surtout y appliquer le tracking du changement !

 

imageimage

Cliquez sur les images pour voir la taille originale

 

Nous allons ensuite créer deux règles métiers :

  1. Lors de la création d’un produit, le statut doit être Nouveau.
  2. Lorsque le statut d’un produit change et qu’il est égal à Nouveau, je lance le WorkFlow SharePoint.

 

image

 

Voici la copie d’écran de la règle métier permettant de lancer le WorkFlow SharePoint :

 

image

 

Ce qui est important ici, ce sont les paramètres :

  1. Type de flux : SPWF : ça c’est standard, et ça permet d’identifier le bon extender
  2. Site du flux : Site sharepoint, classique, n’oubliez pas le “/” en fin d’url
  3. le nom du flux de travail : Ca c’est important : il faut absolument mettre le bon nom du Workflow SharePoint. Vous pouvez le retrouver de deux manières:
    • Le nom est la concaténation du projet Visual Studio et de la classe Workflow qu’il contient, séparé par un “ – “
    • Une fois déployé dans SharePoint, dans l’onglet WorkFlows Site, vous retrouvez le nom des WorkFlows.

 

Une fois la règle métier validée, lors de la création d’un produit, qui prend donc le status Nouveau, le WorkFlow est lancé, et nous avons bien un retour dans Visual Studio :

 

imageCliquez sur l’image pour voir la taille originale

Jusque là, il nous manque toujours le WorkFlow a développer et à déployer dans SharePoint Sourire

Le projet WorkFlow SharePoint

Oh mon dieu, je fais du SharePoint et en plus j’en écris un article, mais où va le monde …

L’idée ici est de dédier tout le process de validation de notre Produit dans SharePoint via les taches WorkFlow.

J’ai poussé un peu le vice à vouloir rapatrier et afficher les informations de notre Produit dans la tache.

Il a donc fallu customiser le formulaire pour faire apparaitre une liste déroulante permettant de définir de valeurs de status d’un produit (je ne l’ai fait ici que pour le status, mais on peut imaginer afficher tous les champs de notre produit issu de MDS)

imageimage

Cliquez sur les images pour voir la taille originale

 

Le projet WorkFlow Visual Studio est assez classique dans l’esprit, n’oubliez pas de bien créer un projet SharePoint à la base :

image

image

image

Mes deux taches à créer sont relativement simple, la première étant un peu particulière:

  1. Elle récupère les informations du flux entrant provenant de MDS (enfin de l’extender qui l’appelle)
  2. Elle crée une tache SharePoint
  3. Elle récupère, grâce à l’objet workflowProperties le champs ApprovalStatus (souvenez vous le champs custom que j’ai crée dans ma liste SharePoint) et lui affecte un nouveau status

 

private void createFirstTask_MethodInvoking(object sender, EventArgs ea)
{
    // Récupérer le XML de MDS

    if (workflowProperties.InitiationData != null)
    {
        var doc = XDocument.Parse(workflowProperties.InitiationData);
        //Console.WriteLine(dataElement.OuterXml); 
        try
        {        //parse the XML documet into a semi-structured object 
            var externalAction =
                (from e in doc.Elements()
                 select new
                 {
                     Type = (string)e.Element("Type"),
                     SendData = (string)e.Element("SendData"),
                     Action_ID = (string)e.Element("Action_ID"),
                     Server = (string)e.Element("Server_URL"),
                     Model_ID = (int)e.Element("Model_ID"),
                     Model_Name = (string)e.Element("Model_Name"),
                     Entity_ID = (int)e.Element("Entity_ID"),
                     Entity_Name = (string)e.Element("Entity_Name"),
                     Version_ID = (int)e.Element("Version_ID"),
                     Member_ID = (int)e.Element("Member_ID"),
                     MemberData = new
                     {
                         Name = (string)e.Element("MemberData").Element("Name"),
                         Code = (string)e.Element("MemberData").Element("Code"),
                         Attributes = e.Element("MemberData").Elements().ToDictionary(ae => ae.Name, ae => ae.Value)
                     }
                 }
                 ).Single();
            var member = externalAction.MemberData;

            // Créer la première tache
            CreateFirstTask.TaskId = Guid.NewGuid();
            CreateFirstTask.TaskProperties = new SPWorkflowTaskProperties();

            CreateFirstTask.TaskProperties.AssignedTo = "DOTMIM\\spertus";
            CreateFirstTask.TaskProperties.DueDate = DateTime.Now.AddDays(1);
            CreateFirstTask.TaskProperties.Title = "Nouveau produit " + member.Name;
            CreateFirstTask.TaskProperties.Description = "Un nouveau produit a été créé : " + member.Name + " Approbation service achat en cours.";

            productName = member.Name;

            // Status d'approbation étant un custom field, je récupère son GUID
            approvalField = workflowProperties.TaskList.Fields["Approval Status"].Id;

            // Affectation du flag à Awaiting Status
            CreateFirstTask.TaskProperties.ExtendedProperties.Add(approvalField, AwaitingStatus);
            firsTaskStatus = AwaitingStatus;

            CreateFirstTask.TaskProperties.PercentComplete = 0.5f;

        }
        catch (Exception)
        {
            throw;
        }
    }
}

 

La deuxième tache est dans la même veine, créant une tache pour le service production :

private void createSecondTask_MethodInvoking(object sender, EventArgs e)
 {

     // Créer la première tache
     CreateSecondTask.TaskId = Guid.NewGuid();
     CreateSecondTask.TaskProperties = new SPWorkflowTaskProperties();

     CreateSecondTask.TaskProperties.AssignedTo = "DOTMIM\\spertus";
     CreateSecondTask.TaskProperties.DueDate = DateTime.Now.AddDays(1);
     CreateSecondTask.TaskProperties.Title = "Approbation service production Produit " + productName + "";
     CreateSecondTask.TaskProperties.Description = "Le produit : " + productName + " est approuvé par le service achat. Approbation service production.";

     // Status d'approbation étant un custom field, je récupère son GUID
     approvalField = workflowProperties.TaskList.Fields["Approval Status"].Id;

     // Affectation du flag à NEW
     CreateSecondTask.TaskProperties.ExtendedProperties.Add(approvalField, AwaitingStatus);

     CreateSecondTask.TaskProperties.PercentComplete = 0.5f;
 }

 

Chacune des taches va venir enrichir la liste des taches des utilisateurs concernés (bon dans mon exemple, je fais office des deux services, debug oblige Sourire)

imageCliquez sur l’image pour voir la taille originale

Et le débugage dans tout ça !?

Débuguer ce Workflow à toutes les étapes.

Il faut bien prendre conscience du mécanisme de fonctionnement de notre ensemble:

  1. Le Workflow est déclenché par un service Windows qui va appelé via les api SharePoint la création d’une tache (la Première tache) C’est donc bien le service Windows qui est le processus porteur et sur lequel on doit s’attacher pour débuguer
  2. Une fois la tache créée, il va falloir attendre qu’un utilisateur valide sa tache, dans SharePoint, pour déclencher la suite (et donc dans notre cas, la création d’une seconde tache). A partir de là, c’est le processus porteur de SharePoint (w3wp.exe) qui devient le processus porteur et c’est sur lui qu’il va falloir s’attacher !

En résumé, si vous voulez débuguer TOUTES les étapes du WorkFlow, vous devez vous attacher à :

  1. Microsoft.MasterDataServices.Workflow.exe
  2. w3wp.exe

Dans Visual Studio, rien de plus simple : Vous vous attachez à TOUS les processus w3wp.exe + Microsoft.MasterDataServices.Workflow.exe:

image

image

Et à partir de là, vous ne devriez plus avoir de problèmes pour débuguer votre WorkFlow MDS dans SharePoint (et qui plus est en version SQL SERVER 2012 Sourire)

Voici la solution complète, au format Visual Studio, qui contient

  1. L’Extender SharePoint Pour Master Data Services 2012
  2. Le projet WorkFlow SharePoint 2010 à déployer

 

SharePointMDSWorkFlow

 

Bon WorkFlow, Bon MDS, Bref … bon courage !