Denne blog-indtastning er mere en "inden for mulige" posten vs. konkrete info.

Vi har et teknisk design, der opfordrer til at oprette et websted i en gruppe af websteder via en manuelt lancerede arbejdsproces. Dybest set, brugerne indtaster data i en ny kunde"" brugerdefineret liste og derefter når de færdig og valideret posten dataproces, Vi har brug at oprette et websted for den pågældende kunde.

Jeg er både en stor fan af deklarativ arbejdsproces samt en svag visual studio arbejdsproces programmør, så jeg ønskede at opfylde kravet om brug af SharePoint Designer.

Jeg planlægger at skrive om dette mere detaljeret (og forhåbentlig forelægge en brugergruppe eller to i det kommende år), Men her er den samlede løsning:

• Oprette en brugerdefineret handling, der integrerer med SPD.
• Den brugerdefinerede handling tillader SPD til at påberåbe sig en webtjeneste og videregive det en streng af XML.
• Webtjenesten lokaliserer rækken i den brugerdefinerede liste og opretter et nyt websted som dataene for den nye klient ved hjælp af en brugerdefineret webstedsdefinition.
• Webtjenesten opdaterer derefter den brugerdefinerede liste med nogle oplysninger som et hyperlink til det nye websted.

Vi overvejet andre tilgange, som event handlere og visual studio baseret workflow. SPD tilgang giver vores slutbrugere lidt mere kontrol over processen. Ydes, der er en masse C#-kode i denne løsning, men det er indpakket inde i en deklarativ arbejdsproces, så vi får nogle af fordelene ved deklarativ arbejdsproces mens tilslutte ibrugtagning oprettelse af websted.

All we need now is an easy tool to automatically migrate SPD workflows around as easily as we can for visual studio workflows and we’ll really be cooking with gas 🙂 I understand that some folk are out there working on this problem and I hope they have some good success with it soon.

</slutningen>

Abonner på min blog.

Jeg har spillet med brugerdefinerede handlinger til SharePoint Designer for nogle gang (Se her for nogle detaljerede stuff, Hvis der interesserer dig).

I min aktuelle projekt, Vi skal gøre nogle temmelig tunge løft og vi vil bruge deklarativ SPD workflow til at styre den tilknyttede forretningsprocesser.

Lang historie kort, Det er helt muligt. Jeg udvidede min Codeplex projekt for at påberåbe sig en "helper service" og nu vi kan påberåbe sig en webservice direkte fra en SPD workflow.

Her er signaturen:

 offentlige streng Senderen(
        GUID WebID, // Forbi runtime environment
        GUID SiteID, // Forbi runtime environment
        streng ListID, // Forbi RTE (ikke kender grunden til, at dette er en streng, ikke en GUID)
        int ListItemID, // Forbi RTE.
        streng XmlMessage) // Bestået af brugeren som erklæret i SPD.

Dette udnytter det faktum, at vi kan få på oplysninger om vigtige arbejdsproces, ligesom webstedet, liste-ID, osv. Det er veldokumenteret i flere steder for dem af jer interesseret i at skabe din egen brugerdefinerede handlinger. Ideen er at udtrække XML-streng, som fastsat af brugeren til at afsende en passende procedure. Sjove ting!

Desværre, Dette er naturligvis en envejs billet ned til "Loosey Goosey" anti-pattern jord, but it’s better than hitting a brick wall 🙂

Er det en anti-pattern, hvis du gør det, selvom du ved, det er en anti-pattern?

Jeg håber, at wrap det inde Codeplex i den nærmeste fremtid. Hvis du er interesseret i mig gøre det., give mig sækken (e-mail eller efterlade en kommentar) and I’ll be that more enthusiastic about doing it 🙂

</slutningen>

Abonner på min blog.

Jeg arbejder på et projekt, der bruger fem forskellige arbejdsgange i SharePoint Designer til at håndtere nogle dokumentgodkendelser. SPD giver de "indsamle data fra en bruger" handling så at vi kan bede brugeren om forskellige bits af oplysninger, som om de godkender det, nogle bemærkninger og måske spørge, hvad de havde til middag forleden nat.

Formularerne, der er aldeles funktionel. De er bundet til en opgaveliste som en indholdstype. De er 100% systemgenereret. Dette er deres styrke og svaghed. Hvis vi kan leve med standardformularen, så er vi gode til at gå. Dog, Vi har ikke for meget kontrol over hvordan SPD skaber form. Hvis vi ikke kan lide at standard opførsel, Vi har brug at ty til forskellige tricks til at komme omkring det (for eksempel, angive prioritet på en opgave).

Jeg havde brug at give et link på skemaerne opgave, der åbnede op Vis egenskaber (DispForm.asxp) af den "relaterede vares" i et nyt vindue. Dette giver et enkelt klik adgang til metadata for den relaterede vares. Dette er hvad jeg mener:

Heldigvis, Vi kan gøre det, og det er ikke meget svært. Generelt, fyre op SPD, Naviger til den mappe, der huser arbejdsproces filer og åbne ASPX-fil, du vil ændre. Disse er netop klassiske XSL-transformering instruktioner, og hvis du har mucked med itemstyle.xsl, Søg eller andre xsl-scenarier, Dette vil være let for dig. Faktisk, Jeg fandt det at være generelt lettere, da de genererede form er noget lettere at følge i forhold til webdelen Kerneresultater en søgning (eller den mareridtsagtige CWQP).

Selvfølgelig, der er en stor faldgrube. SPDS arbejdsgangseditoren forventer fuld kontrol over filen. Hvis du ændrer det, SPD vil lykkeligt overskrive dine ændringer giver højre sæt af omstændigheder. Jeg har to hurtige test for at se hvor slemt det kunne få. De begge forudsætter, at du har udformet en gyldig SPD arbejdsproces, som bruger den "indsamle data fra en bruger" trin.

Test 1:

• Rediger filen ASPX i hånden.
• Teste det. (Kontroller, at dine ændringer var ordentligt gemt og ikke ødelægge noget).
• Åbner arbejdsprocessen og tilføje en ikke-forretningsmæssigt forbundne handling (som "log til historie").
• Gem arbejdsprocessen.

Resultat: I dette tilfælde, SPD ikke oprette formularen igen.

Test 2:

• Gør det samme som #1 undtagen direkte redigere den "Indsaml data fra en bruger" handling.

Resultat: Dette skaber ny form fra bunden, over-skrive dine ændringer.

Afsluttende bemærkninger:

• Mindst to SPD handlinger oprette formularer som dette: "Indsamle Data fra en bruger" og "Tildele at gøre element". Begge disse handlinger’ formularer kan ændres manuelt.
• Jeg var i stand til at generere mine link til dispform.aspx, fordi, i dette tilfælde, elementet relate har altid sin ID indlejret i den relaterede vares URL. Jeg var i stand til at udtrække det og derefter opbygge en <en href> baseret på at levere one-click meta data adgang indslag. Det er usandsynligt, at din webadresse følger denne regel. Der kan være andre måder at få ID for den relaterede vares men jeg har ikke haft til at krydse denne bro, så jeg ved ikke, om bliver til anden siden af kløften.
• Jeg gjorde ikke undersøge, men jeg ville ikke blive overrasket, hvis der er en slags skabelonfil i den 12 hive at jeg kunne ændre, påvirker hvordan SPD genererer standardformularerne (ligesom vi kan ændre alert skabeloner).

</slutningen>

Abonner på min blog!

Jeg har en business scenarie som dette:

• En bruger overfører et dokument til et dokumentbibliotek.
• Hun vælger en indholdstype og indtaster metadata efter behov. Et af felterne meta data er et flag, "Haster".
• Dette udløser en SharePoint Designer arbejdsprocessen,, blandt andet, bruger den "indsamle Data fra en bruger" handling.

"Indsamle Data fra en bruger" opretter et element i en opgaveliste, anmoder om godkendelse til dette dokument.

Jeg havde brug at oprette en visning af opgavelisten, der viste hasteanmodninger om godkendelse.

Løsning: Sætte ord "haster:" i titlen på disse opgaver.

Jeg ville have foretrukket at angive feltet prioritet direkte. Dog, Jeg var ikke i stand til at gøre det af flere årsager:

1. Handlingen Indsaml data giver ikke en mekanisme til at opdatere alle felter undtagen titel (og de ekstra felter, du vil indsamle data).
2. Den "Tildel en at vare" handling har den samme opgave.
3. Det er muligt at indsætte et element i en liste (dvs. indsætte et element i hverv listen direkte) men dette ikke handlingen blokering. Det betyder, at arbejdsprocessen ikke venter for brugeren at udføre opgaven.

Jeg fandt et par tilgange inden (Heldigvis) indser vi bare kunne sætte "presserende" i titlen.

1. Start en arbejdsproces på listen over opgaver selv, så når en ny opgave er oprettet, det en eller anden måde krydse referencer tilbage til det dokument, der startede den første workflow, Træk værdien presserende flag og opdatere prioritet efter behov.
2. Gøre noget ligende med en event modtager. På Opret opgave, Find det tilknyttede dokument og opdatering prioritet efter behov.
3. Brug "oprette listeelementet" handling i forbindelse med "Vent for feltet ændring" handling og en event modtager. Hvis vi opretter et listeelement, Vi kan angive alle de felter, vi vil. Bruge en begivenhed modtager opdatere den oprindelige vare, når brugeren afslutter opgaven og "Vent for feltet ændring" aktionens betingelse ville være opfyldt og arbejdsprocessen vil fortsætte. (For anden grund, Jeg havde mere eller mindre afgjort på denne tilgang før klogt beslutter at gå væk i et stykke tid).

Der er en ulempe at min løsning (bortset fra det åbenlyse faktum, at kun teksten af titlen tyder uopsættelighed). Siden "indsamle feedback" accepterer kun hårdt kodet titel navne, Jeg skal bruge to forskellige indsamle feedback handlinger, hvis eneste forskel er, at hard kodet titel.

Men, i det mindste er der en løsning, der ikke kræver hændelsesmodtagere eller brugerdefinerede SPD handlinger.

Hvis nogen har løst det på en mere smart måde, Lad mig vide.

</slutningen>

OPDATERING: Madjur Ahuja påpeger dette link fra en nyhedsgruppe diskussion: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Det er temmelig endelige.

===

Vi ønsker ofte at integrere hyperlinks til InfoPath-formularer i e-mails sendt fra SharePoint Designer arbejdsgange. Når brugere modtager disse e-mails, de kan klikke på linket fra e-mailen og gå direkte til InfoPath-formularen.

Denne monster URL konstruktion virker for mig:

http://server/sites/departments/Technical Services/InformationTechnology/HelpDesk/_layouts/FormServer.aspx?XmlLocation=/sites/departments/Technical Services/InformationTechnology/HelpDesk/REC REM RED Forms/REC2007-12-18T11_33_48.XML&Kilde = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Erstatte fed rød tekst med navnet på formen, som vist i følgende skærmbillede:

Bemærk at der er en masse af hard-kodet sti i URL, samt en URL-kodet komponent. Hvis det er for svært at oversætte til din specifikke situation, Prøv at dreje på indberetninger til formularbiblioteket. Sende en formular og når du får e-mailen, Se kilden til e-mail og du vil se alt hvad du behøver at omfatte.

Snu læsere vil måske bemærke at ovenstående e-mail kroppen også viser et link, der har direkte adgang til opgave via en filtreret visning. Jeg planlægger at forklare det nærmere i en kommende post.

</slutningen>

Jeg har implementeret en arbejdsproces ved hjælp af SharePoint Designer i et websted, som er hovedsagelig skrivebeskyttet til "NT_AUTHORITYAuthenticated brugere" (dvs. alle). Der er et formularbibliotek til et InfoPath-formular. Der er en tilknyttet arbejdsprocessen opgavelisten så godt, så Hvornår arbejdsprocessen fungerer, Det kan tildele opgaver til personer.

Jeg bryde tilladelse til listen formularer bibliotek og opgave, så alle godkendte brugere kan oprette formularer og opdatere deres tildelte opgaver.

Jeg test med min lav-privilegier testkonto.

Jeg kan fylde ud og gemme en formular til biblioteket? –> Ja

Kan jeg få adgang til opgaven fra et e-mail-link? –> Ja

Jeg kan se linket Redigér arbejdsprocessen opgave –> Ja

Jeg kan klikke på linket? –> Nej … Permission Denied.

Hvorfor kan jeg ikke se linket Redigér der nægter mig tilladelse, når jeg klikker på det? Thats ikke hvordan det er meningen at arbejde…

Jeg går gennem sikkerhedskonfiguration igen, meget tæt. Jeg gør det igen. Jeg overveje at slette dette indlæg fordi jeg selvfølgelig ikke vide noget om sikkerhed.

Endelig, Jeg søger Internets. Jeg finder dette meget usandsynligt MSDN forumtråd: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Plakaterne synes at være at foreslå, at den simple handling eksporterende arbejdsprocessen til en kørsel fad vil lave en Mos sikkerhed oplag? Jeg kan næsten ikke tro jeg lige har skrevet. Jeg mindet om South Park episoden om den 9/11 sammensværgelse hvor Stan beder vores Preznit, "Virkelig?" igen og igen.

Så, intet at tabe, Jeg fyre op SPD, Højreklik på arbejdsprocessen og gemme det til min c:\ kørsel. Det ville være c:\ kørsel på min laptop. Jeg glæder mig over min skulder hele tiden, så at ingen vil bede mig, "hvorfor du gemmer denne arbejdsproces til din bærbare computer?"

Utrolig, det løser mit problem. Jeg kan redigere opgave.

Jeg udpege hermed dette at være den mest Bizarre Workflow løsning af 2007.

</slutningen>

Vi ønsker ofte at sende en e-mail, der indeholder et hyperlink til elementet eller dokumentet, der udløste arbejdsprocessen. Vi kan bruge aktuelle element "kodet absolut URL-adresse" til dette formål. Dog, Det synes altid at bruge "http" for URL-protokollen. Hvis dit websted kører på HTTPS, så det ikke vil arbejde for dig.

Så vidt jeg ved, der er ingen ud af boksen løsning på problemet. Hvis du skal bruge HTTPS, du har ingen af indstillingen boks.

At løse det, oprette en brugerdefineret handling, der giver en streng Erstat funktion at bruge i din arbejdsgang. Alternativt, bruge en 3rd part værktøj som den fremragende pakke her: http://www.codeplex.com/spdwfextensions 🙂

</slutningen>

Forum brugere spørge lejlighedsvis: Hvorfor sætter SharePoint Designer ???? ind i min e-mail i stedet for en feltværdi?

En af grundene til dette sker er fordi den variabel, som du henviser til er null.

Dette kan ske, fordi du forsøger at henvise til et felt fra den aktuelle vare"" men brugeren er aldrig trådt en værdi i at formularfelt.

<afslutning />

Scenario: I en arbejdsproces til SharePoint Designer, Du skal afgøre, om et date-felt er tomt.

Problemet: SPD giver ikke en direkte metode til sammenligning af datoer til andet end en dato. Du kan ikke oprette en betingelse, som denne: "Hvis [DateField] lig med Tom".

Løsning: Konvertere en dato til en streng. Bruge strengsammenligning til at bestemme, hvis datoen er tom.

Skærmbilleder:

De følgende skærmbilleder viser, hvordan du gør dette. I dette scenario, et felt på en vare, "Miljøtilladelser:Først tillade rykker dato", er indsendt og arbejdsprocessen brande i svar.

Noter:

Når jeg har prøvet dette, Jeg blev glædeligt overrasket over at erfare, at det virker. Jeg var bekymret for, at SharePoint Designer kan forbyde streng tildeling (Variabel:StringReminderDateDate) men det tillod det.

Jeg var også bekymret at tillader det, Værdien kan være null og enten sprænge WF på kørselstidspunktet eller måske hæve den globale temperatur 1/2 en grad, men disse bekymringer var ubegrundet.

</slutningen>

Bare en hurtig bemærkning, at der er en meget vigtig forskel mellem disse to definitioner:

<FieldBind felt = "InParam1" DesignerType = "StringBuilder" Id = "2" Tekst = "Input parameter #1" />

versus:

<FieldBind felt = "InParam1" Id = "2" Tekst = "Input parameter #1" />

Først viser gerne dette i SPD:

mens de sidstnævnte shows som dette:

Jeg er ikke sikker på, hvor nyttige disse skærmbilleder er, men jeg bestræber mig på at gøre dem, så du bliver nødt til at se dem 🙂

Observation er dette: StringBuilder tillader jer hen til opbygge en streng (naturligvis) ved at blande sammen Strengkonstanter og arbejdsprocesdata (via "Tilføj opslag" knappen i nederste venstre hjørne). Når du bruger knappen Tilføj opslag, det indsætter en token i form"[%token %]". Når SharePoint påberåber sig din brugerdefineret handling, (C# kode i mit tilfælde), SharePoint passerer tokenet, selv, ikke værdi af token. Hvis du bruger designer standardtypen (den anden type), SharePoint udvider token og passerer faktiske værdi af tokenet til din handling.

StringBuilder = dårlig, standard designer type = godt.

Selvfølgelig, Det er ikke, hvad jeg virkelig mener. Bare ikke prøve og passerer en parameter til din brugerdefineret handling, når designeren Skriv = StringBuilder. Bruge standardtypen designer og kæde en StringBuilder skal det op foran hvis du har brug at opbygge komplekse strenge i din arbejdsgang (hvilket i øvrigt er præcis, hvad man gør hen til skabe en dynamisk genstand for handlingen e-mail, men det er et emne til en anden blog-indtastning, har har).

<afslutning />