Jeg skrev en detaljeret artikel for et par uger siden, der beskriver, hvordan du opretter et SharePoint Designer arbejdsprocessen, der sender en opgave påmindelse e-mail dagligt. Det har været offentliggjort på den nye SharePoint Magazine site. Mere generelt, artiklen viser hvordan du opretter en looping struktur i SPD.

Bladet har en bred vifte af artikler, herunder, blandt andet, meget tekniske ting, interviews og industri nyheder. Jeg vil anbefale du tilføje det til din RSS-feed.

Hvis du har et produkt eller en tjeneste at sælge, Jeg vil også overveje annoncering på sitet. Det er starten til en stærk start med flere tusinde par øjne kigger på det allerede. Der er sikker på at vokse.

Endelig, Hvis du har kløe til at skrive noget og få det ud foran et større publikum, Dette er en fantastisk tid og sted til at ridse det.

</slutningen>

Abonner på min blog.

Mark Miller over på Slutbrugeren SharePoint har sendt min seneste artikel om brug af SharePoint Designer til at skabe stor arbejdsprocesløsninger op på hans hjemmeside. Tjekke den ud.

I denne artikel, Jeg taler om designprocessen og, mere detaljeret, Hvordan at oprette en pålidelig og repeterbare test proces ved hjælp af SharePoint-funktioner (brugerdefinerede lister, webstedsskabeloner). Artiklen henvender sig til slutbrugere, men tilgangen er godt for udviklere også.

</slutningen>

Abonner på min blog.

Sidste uge, Jeg arbejdede ud, hvordan man loop og gennemføre en tilstandsmaskine ved hjælp af SharePoint Designer og nævnt, som en sidebemærkning, Jeg vil sandsynligvis skrive et blogindlæg om bedre workflow logføring.

Godt, Minna Rajput slå mig til det. Have et kig.

Gemme logdata til en brugerdefineret liste, der synes bedre end ved hjælp af den regelmæssige arbejdsgangshistorikken:

• Det er bare en brugerdefineret liste, så kan du eksportere det til excel meget nemt.
• Du kan oprette visninger, dynamisk filtrere dataene, osv.
• Det er ikke omfattet af auto-opgøret får du med regelmæssige arbejdsgangshistorikken.

Der er nogle risici / ulemper:

• Mange kørende arbejdsprocesser med en masse logføring kunne forårsage for meget data der skal skrives til listen.
• Måske du * gøre * ønsker automatiske udrensning. Du får ikke denne funktion med denne tilgang (uden kodning).
• Sikkerhed er tricky. For at skrive til listen, brugeren skal have tilladelse til at gøre det.. Det betyder, at det sandsynligvis ikke er egnet til enhver form for "officielle" revision da brugeren kunne opdage listen og redigere det.. Dette kan løses med nogle brugerdefinerede programmering.

</slutningen>

Abonner på min blog.

Dette sidste uge jeg færdig off en proof of concept projekt for en klient i Manhattan. Ved implementeringen af løsningen, Jeg løb ind i en anden mangel ved MOSS KPI'er (Se her for en tidligere KPI-spørgsmålet og min løsning).

Baggrund: Vi brugt SharePoint Designer arbejdsprocessen til at modellere en temmelig komplekse multi-måneders lang business proces. Som det tøffede, det vil opdatere nogle status oplysninger på en liste. KPI'er bruge disse data til at gøre deres mojo.

Vi besluttede at oprette et nyt websted, hver gang en ny af disse forretningsprocesser skydes i gang. Bortset fra selve arbejdsprocessen, disse websteder vært flere dokumentbiblioteker, bruge målgrupper og så videre. Bare en masse ting til at hjælpe med samarbejde blandt de interne ansatte, rejser medarbejdere og klienten er deltager forretningspartnere.

Vi ønskede også at vise nogle KPI'er, at overvåge den generelle sundhed i denne specifikke forretningsproces, som støttes af staten arbejdsprocesdata og vises ved hjælp af KPI'erne.

Endelig, Vi anvendte KPI-listeelementer, der gør en optælling på en visning på en liste i stedet (i modsætning til at trække fra en anden datakilde, ligesom excel eller SQL).

Problemet: Som du kan forestille dig, forudsat at vi skulle bære den grundlæggende idé frem i en produktion verden, Vi ønsker en webstedsskabelon. Klargøre et nyt websted baseret off en "business process" skabelon.

Problemet er, at du ikke synes at få en velfungerende KPI måde. Når jeg opretter et nyt websted baseret på en skabelon med en KPI-liste og KPI-webdelen, det nye websted KPI-data er brudt. Det nye websted KPI-listen punkter på uanset kilde du defineret når du først gemmes det som en skabelon.

Som eksempel:

• Oprette et nyt websted og bygge det til perfektion. Dette websted omfatter KPI-data.
• Gemme det som en skabelon.
• Oprette et nyt websted og base hvis off skabelonen.
• Dette nye site KPI-listeelementer’ kilder peger på webstedsskabelonen, ikke det aktuelle websted.

Instantiering proces korrekt ikke URL.

Jeg forsøgt at løse dette ved at angive en relativ URL-adresse, når du definerer den KPI-liste vare. Dog, Jeg kunne ikke få nogen variation af det til at arbejde.

Jeg vil altid pair op på disse "problem" blog-indlæg med en slags løsning, men i dette tilfælde har jeg ikke et godt. Det bedste jeg kan finde er, at du skal gå ind på webstedet nyligt klargjorte og ordne alt manuelt. UI gør det endnu sværere fordi ændre Webadressen på kildelisten forårsager en refresh, så du virkelig nødt til at omdefinere det hele fra bunden.

Hvis nogen kender en bedre måde at håndtere dette, Skriv venligst en kommentar.

</slutningen>

Jeg har for nylig lært, at det er muligt og endda ret nemt at oprette en stat maskine arbejdsgang ved hjælp af SharePoint Designer. Nødvendighed er mor til opfindelsen og alt det gode ting og jeg havde et behov i denne uge, som søgte en opfindelse. Tilfældigvis, Jeg kom på tværs af denne MSDN forumindlæg samt. Min personlige erfaring i denne uge og at "uafhængig bekræftelse" giver styrke til min overbevisning. Jeg planlægger at skrive om dette på større længde med en fuld blæst eksempel, men her er essensen af det:

• Metoden udnytter, at en arbejdsproces kan ændre et listeelement, derved udløser en ny arbejdsproces. Jeg har normalt betragtes dette at være en plage og endda blogges om brug af semaforer til at håndtere det..
• SharePoint giver mulighed for flere uafhængige arbejdsprocesser til at være aktiv mod et bestemt listeelement.

Du konfigurerer det:

• Design din tilstandsmaskine (dvs., staterne og hvordan stater overgang fra den ene til næste).
• Gennemføre hver stat som separat arbejdsproces.
• Konfigurere hver af disse statslige arbejdsprocesser udføres som svar på enhver ændring i listeelementet.

Hver tilstandsarbejdsproces følger denne groft mønster:

• Efter initialisering, bestemme om det skal virkelig køres af inspicerende stat oplysninger i de "nuværende punkt". Afbryde hvis ikke.
• Gøre arbejdet.
• Opdatere den aktuelle vare"" med nye tilstandsoplysninger. Dette udløser en opdatering af den aktuelle vare og fyrer alle statslige arbejdsprocesser.

Bortset fra den indlysende fordel kan at man oprette en deklarativ tilstandsarbejdsproces maskine, alt, hvad tilstandsoplysninger er fantastisk til at opbygge KPI'er og interessant visninger.

Det har en temmelig betydelig ulempe — standard workflow history tracking is even more useless than normal 🙂 That’s easily remedied, dog. Gemme alle dine revision typeoplysninger i en brugerdefineret liste. Det er nok en god ide selv for vanille sekventiel arbejdsproces, but that’s for another blog post 🙂

Jeg kalder dette en "mea culpa" fordi jeg har, Desværre, sagt mere end én gang på fora og andre steder, at man skal bruge visual studio til at oprette en maskine tilstandsarbejdsproces. Der er simpelthen ikke sandt.

</slutningen>

Abonner på min blog.

Det er muligt at forårsage en endeløs løkke i en SharePoint Designer arbejdsprocessen. En fælles gennemførelse mønster som dette forårsager problemet:

• Oprette en arbejdsproces og tilknyttes en liste.
• Angive at det skal start på oprette nye emner og opdatering af eksisterende poster.
• Et trin i arbejdsprocessen opdaterer et felt i "Aktuelle element".
• Da det aktuelle element ændret, arbejdsprocessen starter forfra.

At forhindre denne endeløs sløjfe, gennemføre en simpel semaphore:

• Tilføje en webstedskolonne (eller kolonne på listen/biblioteket hvis du ikke bruger indholdstyper).
• Skjule det fra siden Rediger (let at gøre, hvis en webstedskolonne via dets egenskaber, ikke så let, hvis en listekolonne).
• I arbejdsprocessen, kontrollere hvis værdien af kolonnen semaphore er tom.
• Hvis det er tomt, sæt den til en ikke-tom værdi og fortsætte.
• Hvis er imidlertid ikke er tomt, Afslut straks.

Dette kan blive en temmelig nuanceret løsning, afhængigt af virksomhedens behov og så videre, men det har været et brugbart mønster, når jeg har brug for det.

</slutningen>

Abonner på min blog.

Som mange ved, skabelonen medarbejder uddannelse leveres af Microsoft her har en fejl, at vi kan reproducere følgende fremgangsmåde:

• Oprette en klasse med en max størrelse på 10 studerende.
• Registrer –> Alt tilgængelige pladser ordentligt formindsker af en. Resultat: 9 ledige pladser.
• Uregistreret: –> Bug. Samlede tilgængelige pladser bør forøges med en. Det gør ikke. Resultat: 9 pladser pr SharePoint, men i virkeligheden, der er 10 ledige pladser.

Løsning: Bruge SharePoint Designer til at korrigere arbejdsprocessen.

Første, Åbn webstedet. Mappelisten for mig ligner det:

Hvis vi har et kig på "deltager registrering" arbejdsproces, Vi ser, at der er et skridt, der er mærket "Håndhæve siddepladser politik". Det ser sådan ud:

Dette trin i arbejdsprocessen opdateres elementet forøgelse "fyldt sæderne" metadata kolonne på banen. Hvis vi trækker det i flere detaljer, Vi ser dette:

Der er alle de oplysninger, vi skal rette framelding arbejdsproces.

Hvis vi flip-over til arbejdsprocessen framelding, der er ingen lignende trin i arbejdsprocessen. Tilføj det som følger:

1: Udvid "deltager framelding" og lukke sig op XOML (Se første skærmbillede hvis du er tabt).

2: Tilføje en ny arbejdsprocesvariablen, "Nye fyldte sæder" af typen "Tal".

3: Tildele en værdi til "nye fyldt pladser" som vist:

4: Formindske de fyldte pladser ved 1:

5: Opdatere elementet relaterede kursus:

6: Sørg for, at alle trin er i den rigtige rækkefølge. For mig, Det ser sådan ud:

7: Afslutte arbejdsprocessen for at genopbygge det.

8: Test.

</slutningen>

Abonner på min blog.

En af de nye mønstre jeg finde når du udformer SharePoint løsninger udnytter SharePoint Designer arbejdsprocessen og en hændelse receiver.

Her er en Forretningsscenario at sætte det i sammenhæng:

• Jeg overfører et dokument til en doc lib.
• Jeg sparke off flere trin arbejdsproces oprettet ved hjælp af SharePoint Designer.
• På et tidspunkt under denne proces, arbejdsproces tildeler en opgave til en person (via indsamle data fra brugeren eller tildele en opgave).
• Vi ønsker at bruge en KPI-indikator til at holde styr på hvor længe denne opgave er afventer afslutningen. Nøgletallet viser grøn til opgaver, der er afsluttet eller due mere end 3 dage fra nu. Det viser gul, hvis opgaven er forfalden i morgen eller i dag. Det viser rød, hvis opgaven er forfaldne.
• Her er kickeren: Jeg ønsker den dato, der drev KPI skal være ferie-bevidste.

Jeg kan ikke beregne en ferie-aware due dato i SharePoint Designer arbejdsprocessen meget nemt. Jeg ville have til at oprette en brugerdefineret handling eller bruge en 3rd part værktøj. Dog, Det er let nok at beregne sådanne en dato i en event modtager. Flette disse to sammen og vi få et mønster som denne:

• Definere en skjult Ja/ingen webstedskolonne på dokumentbiblioteket mærket "DoCalcualteDueDate".
• Initialisere det til false.
• På et passende tidspunkt i arbejdsprocessen (strømsparetilstand. lige før Indsaml data"" handling), tildele værdien til True.
• En ItemUpdate() hændelse modtageren ser til at se, hvis "DoCalculateDueDate" er sandt. Siden begivenhed modtageren kører på hver opdatering, "DoCalculateDueDate" er normalt falsk.
• Når arbejdsprocessen tildeler DoCalculateDueDate til true, hændelse modtageren beregner den ferie-aware behørig dato.
• Når hændelsen modtageren gør denne beregning, det indstiller flaget DoCalculateDueDate til false.

I sidste ende, SPD workflow er kommunikeret med en event modtager via DoCalculateDueDate semaphore og vi har ferie-aware grund datoer, der er tildelt den helt korrekte øjeblikket i arbejdsprocessens liv. SharePoint Designer kontrol når forfaldsdatoen er tildelt men begivenhed modtageren udfører de faktiske beregning og tildeling.

</slutningen>

Abonner på min blog.

OPDATERING: Jeg har forsket i, hvordan man kan integrere en SPD workflow i en webstedsdefinition. Denne MSDN forum kæde har nogle interessante oplysninger. Det er ikke afgørende, men point til sti gennem junglen.

Jeg giver dette indlæg en anelse særling "observerede adfærd" da jeg er lidt forsigtig med at drage konklusioner fra det. SPD arbejdsprocesser er … temperamentsfuld.

Mennesker spørger ofte / gad vide / fretting over flytter SPD arbejdsprocesser fra ét sted til et andet. I dag, Jeg har fulgt disse trin, og disse bemærkninger:

• Jeg oprettede en arbejdsproces ved hjælp af SharePoint Designer i et websted, der er knyttet til et dokumentbibliotek.
• Tilknyttet dokumentbiblioteket husede allerede flere dokumenter.
• Jeg gemte webstedet som en skabelon.
• Når jeg gemt webstedet som en skabelon, Jeg gemte indholdet.
• Jeg oprettede et nyt sted i den samme gruppe af websteder ved hjælp af denne skabelon.

På dette punkt, Jeg prøvede at køre arbejdsprocessen. Det ophævet straks selv log besked, "Mislykkedes på start".

Jeg havde forventet dette. Jeg har lave forventninger, når det kommer til at færdes SPD arbejdsprocesser.

Jeg fortsatte:

• Åbnes webstedet i SharePoint Designer.
• Havde et smugkig på arbejdsprocessen. Det virkede fint.
• Jeg har klikket på "Udfør".
• Jeg løb arbejdsprocessen.

Denne gang, Det fungerede fint.

Jeg vil tilføje, at denne arbejdsgang bruges den "indsamle data fra brugeren" handling, som er en relativt kompleks aktion under kølerhjelmen.

Jeg forsigtigt konkludere, at processen med "efterbehandling" arbejdsprocessen forårsaget SPD tilknyttes arbejdsprocessen SPD ordentligt med det nye dokumentbibliotek. Afslutningsvis også XOML og andre XML-artefakter er rimeligt "løs". De er ikke super tæt koblet til dokumentbiblioteket.

Hvad betyder dette betyde? Forudsat det er en pålidelig og reproducerbar proces, der er mindst en ru metode vi kan bruge til at flytte dem rundt. Jeg ved ikke, hvis dette vil arbejde, hvis vi krydsede site collection grænser eller endda mere drastisk, hele nye bedrifter (strømsparetilstand. dev til fase at prod).

Hvis du læser dette og tilbøjelig, kan du skrive en kommentar eller e-mail mig din SharePoint Designer migration historie. Jeg vil gerne opdatere denne postering med nogen indsigt, således tilbydes.

</slutningen>

Abonner på min blog.

Det er ofte nyttigt at gemme statusoplysninger på en brugerdefineret liste som en godkendelseskode, som aldrig skal manipuleres direkte af slutbrugeren. Dette er et almindeligt scenarie for virksomheder. Jeg har arbejdet på et projekt i år, der genererer forskellige status og påmindelse datoer via SharePoint Designer arbejdsgange, derefter køre KPI'er og generelt støtte tidskritiske forretningsprocesser.

Bruge en webstedsindholdstype / kolonne for at opnå denne effekt.

Oprette en webstedsindholdstype med statuskolonnen som vist:

Bemærk "Status (for Demo)" felt nederst.

Næste, Klik på kolonnenavnet adgang til kolonnens egenskaber. Vælg "skjult (Vises ikke i formularer)" i sektionen Kolonneindstillinger som vist:

Dette fjerner området fra standard Rediger/opdatering former. Dog, Det er stadig tilgængelig i visninger, KPI'er, objektmodellen og andre steder du ønsker at bruge det, herunder SPD workflow.

</slutningen>

Abonner på min blog.