MEA Culpa — SharePoint Designer * kan * skapa statliga maskin arbetsflöden

4 svar

Jag har nyligen lärt mig att det är möjligt och även ganska lätt att skapa en stat maskin arbetsflöden med SharePoint Designer. Nöden är mamma till uppfinningen och så bra grejer och jag hade ett behov i veckan som såg för en uppfinning. Coincidentally, Jag kom över denna MSDN foruminlägg samt. Min personliga erfarenhet denna vecka och den "oberoende bekräftelsen" ger styrka till min övertygelse. Jag planerar att skriva om detta mer utförligt med ett fullskaligt exempel, men här är kontentan av det:

  • Metoden utnyttjar det faktum att ett arbetsflöde kan ändra ett listobjekt, därmed utlösa ett nytt arbetsflöde. Jag har normalt anses detta vara en olägenhet och även bloggat om med semaforer att hantera det..
  • SharePoint gör flera oberoende arbetsflöden sig vara aktiv mot en specifik lista objekt.

Konfigurera den:

  • Designa din tillståndsdator (dvs., staterna och hur stater övergången från en till nästa).
  • Genomföra varje stat som separata arbetsflöde.
  • Konfigurera var och en av dessa statliga arbetsflöden att köra som svar på ändringar i posten.

Varje stat arbetsflöde följer denna grova mönster:

  • Vid initiering, avgöra om det verkligen ska köra genom att inspektera statusinformation i "aktuellt objekt". Abortera om inte.
  • Göra arbetet.
  • Uppdatera det aktuella objektet"" med information om nya. Detta utlöser en uppdatering till det aktuella objektet och bränder av alla arbetsflöden som staten.

Förutom den uppenbara fördelen kan att man skapa en deklarativ staten maskin arbetsflöde, allt som statusinformation är fantastiskt för att skapa KPI: er och intressant visningar.

Den har en ganska betydande nackdel — standard workflow history tracking is even more useless than normal 🙂 That’s easily remedied, men. Lagra alla dina typ granskningsinformation i en anpassad lista. Det är nog en bra idé även för vanilj sekventiella arbetsflöden, but that’s for another blog post 🙂

Jag kallar detta en "mea culpa" eftersom jag har, Tyvärr, sa mer än en gång på forum och på andra håll att man måste använda visual studio för att skapa ett statligt maskin arbetsflöde. Det är helt enkelt inte sant.

</slutet>

Prenumerera på min blogg.

Technorati Tags:

4 tankar på "MEA Culpa — SharePoint Designer * kan * skapa statliga maskin arbetsflöden”

  1. Jaustral skrev:
    Hej Paul,
    Hur många stater sysslar du med? Jag får bara ha två olika aktiva arbetsflöden när jag går till sidan arbetsflöde?
    Bästa,
    Juan.
    Svar ↓
  2. Sanjeev Rajput
    Jag vill verkligen läsa de full exempel. Förhoppningsvis kan en av er hjälpa att klargöra några mardrömmar som jag har haft med min liknande process. Jag är vid den punkt där jag är redo att börja från färska.
    Svar ↓
  3. Paul Galvin
    Det är en riktigt intressant strategi sätter en utropen peka på större poäng att SPD kan skapa stat maskin arbetsflöden.
    Jag vet inte om det finns betydande skillnader prestandamässigt mellan vad du beskriver och vad jag beskriver. I mitt fall denna vecka, prestanda är inte ett problem eftersom detta särskilt arbetsflöde är en långvarig affär (16 eller fler veckor från början till slut) och det är aldrig mer än ett par dussin aktiva när som helst. Om det fanns ett tiotal starta och köra varje timme … Det skulle vara en annan historia. Jag tror att prestanda och arbetsflöde i allmänhet är en mycket dimmig fråga.
    Jag vet inte om du kör din egen blogg eller inte. Om du gör, du borde överväga att skriva om din inställning mer i detalj. Om inte, Jag skulle mer än gärna att ringa dig "gästbloggare" och ladda upp ditt inlägg till min blogg.
    Tack för kommentaren. Det är en av de bästa jag har kunnat få fram på min blogg!
    –Paul G
    Svar ↓
  4. Mike Atkins
    Jag genomfört tillståndsdatorn använder en separat lista för att hålla staten under de statliga övergångarna. Huvudsakliga arbetsflödet skapas en artikel här och anger starttillståndet. Jag använde en enda, separat, arbetsflödet för att hantera alla stater, med en "IF-då-ELSEIF" struktur (i "Steg 1") på möjliga staterna.
    För varje stat, allt jag behövde göra var att få ett svar från en användare.
    Mitt exempel var ett sekventiellt godkännande av flera nivåer, där varje steg (representeras av en stat) kunde ha olika möjliga efterträdare. Detta innebar att varje användare hade (potentiellt) olika alternativ tillgängliga i en val meny. Min "steg två" var också en "IF-THEN-ELSE" struktur som anses alla möjliga svar (från alla stadier), och då bestämde på vad nästa tillstånd bör. "Steg 3" Ställ sedan in den staten, och arbetsflödet avslutades.
    Denna metod har den (uppenbara) Fördelen med händer inom ett enda (sekundära) arbetsflöde. Men, omfattningen av vad som kunde åstadkommas i det här arbetsflödet är mer begränsade att man skulle ha med arbetsflöden för varje stat. Jag undrar, men, Vad för slags prestanda träff äger rum om alla arbetsflöden som enskild stat startar (om än slutar omedelbart därefter).
    Också, Jag använder en sekundär lista (med sitt eget arbetsflöde) att representera övergången mellan stater som denna process kan vara bara en del av ett större arbetsflöde. När det huvudsakliga arbetsflödet startar stat maskin processen, Det går in en vänta-stat, och vinning när det "looping" har termintaed. Jag också överväger möjligheten att min huvudarbetsflödet kanske också vill ändra data i posten ursprungliga, och jag ville slippa onödiga "skottlossningar" av staten maskin arbetsflödet.
    Svar ↓

Lämna ett svar till Paul Galvin Avbryt svar

Din e-postadress kommer inte att publiceras. behövliga fält är markerade *