Mea Culpa — SharePoint Designer * kan * oprette arbejdsprocesser, statslige maskine

4 Svar

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.

Technorati Tags:

4 tanker om ”Mea Culpa — SharePoint Designer * kan * oprette arbejdsprocesser, statslige maskine”

  1. Jaustral skrev:
    Hej Paul,
    hvor mange stater du beskæftiger sig med? Jeg får kun at have to forskellige aktive arbejdsprocesser, når jeg går til indstillingssiden for arbejdsproces?
    Bedste,
    Juan.
    Svar ↓
  2. Minna Rajput
    Jeg vil virkelig gerne læse de fulde eksempler. Forhåbentlig kan en af jer tydeliggøre nogle mareridt, jeg har haft med min lignende proces. Jeg er på det punkt, hvor jeg er klar til at starte fra frisk.
    Svar ↓
  3. Paul Galvin
    Det er en virkelig interessant tilgang sætter et udråbstegn pege på de større punkt, at SPD kan opretter stat maskine arbejdsprocesser.
    Jeg ved ikke, hvis der er væsentlige forskelle performance-wise mellem hvad du skitsere og hvad jeg skitsere. I mit tilfælde denne uge, ydeevne er ikke et problem, fordi denne særlige arbejdsproces er en længerevarende affære (16 eller flere uger fra start til slut) og der er aldrig mere end et par dusin aktiv når som helst. Hvis der var et par dusin starter og kører hver time … Det ville være en anden historie. Jeg tror, ydeevne og arbejdsprocessen i almindelighed er en meget diset emne.
    Jeg ved ikke, hvis du kører din egen blog, eller ikke. Hvis du gør, du burde overveje at skrive om din tilgang i flere detaljer. Hvis ikke, Jeg ville være mere end glade for at kalde dig en "gæsteblogger" og upload dit indlæg til min blog.
    Tak for kommentaren. Det er en af de bedste jeg har kunnet fremkalde på min blog!
    –Paul G
    Svar ↓
  4. Mike Atkins
    Jeg gennemført Tilstandsmaskinen ved hjælp af en separat liste til at holde staten under statens overgange. De vigtigste arbejdsproces oprettede en vare her og starttilstand. Jeg brugte en enkelt, separat, arbejdsprocessen til at håndtere alle staterne, ved hjælp af en "Hvis-så-ELSEIF" struktur (i "Trin 1") på de mulige tilstande.
    For hver stat, alt jeg skulle gøre var at få et svar fra en bruger.
    Mit eksempel var en sekventiel godkendelse i flere niveauer, hvor hvert trin (repræsenteret af en tilstand) kunne have forskellige mulige efterfølgere. Dette betød, at hver bruger havde (potentielt) forskellige muligheder til rådighed i en valg menu. Min "trin to" var også en "Hvis-så-ellers" struktur, der anses for alle de mulige svar (fra alle faser), og derefter besluttede på hvad den næste tilstand skal være. "Trin 3" derefter indstille denne stat, og arbejdsgangen endte.
    Denne metode har den (indlysende) fordel af sker inden for en enkelt (sekundære) arbejdsproces. Dog, af hvad der kunne ske i denne arbejdsproces er mere begrænset, at man ville have med arbejdsprocesser for hver stat. Jeg tænkte på, dog, hvilken slags ydeevne hit finder sted hvis alle af de enkelte statslige arbejdsprocesser starter (omend slutter umiddelbart herefter).
    Også, Jeg bruger en sekundær liste (med sin egen arbejdsproces) repræsenterer overgangen mellem stater, som denne proces er muligvis kun en del af en større arbejdsproces. Når den primære arbejdsproces starter maskinen tilstandsproces, det går i tilstanden vent, og når de "springer" har termintaed. Jeg overvejede også muligheden for, at min primære arbejdsproces kan godt vil ændre data i det oprindelige element på listen, og jeg ønskede at undgå unødvendige "fyringer" af maskinen tilstandsarbejdsproces.
    Svar ↓

Efterlad et svar til Paul Galvin Annuller besvarelse

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *