Kategori Arkiv: SharePoint arbetsflöde

Skapa webbplatser (SPWeb) via SharePoint Designer arbetsflöde

Denna bloggpost är mer av en "i sfären av möjliga" posten vs. konkret information.

Vi har en teknisk design som för oss att skapa en webbplats i en webbplatssamling via en manuellt lanserade arbetsflödesprocess kallar. I princip, användarna kan ange data i en "ny kund" anpassad lista och sedan när de har avslutat och validerade data entry processen, Vi behöver skapa en webbplats för kunden.

Jag är ett stort fan av deklarativa arbetsflöden såväl som en svag visuell studion arbetsflöde programmerare, så jag ville uppfylla kravet med SharePoint Designer.

Jag planerar att skriva om detta mer i detalj (och förhoppningsvis presentera för en grupp eller två under det kommande året), men här är den totala lösningen:

  • Skapa en anpassad åtgärd som integrerar med SPD.
  • Den anpassade åtgärden gör att SPD att anropa en webbtjänst och skicka den en sträng av XML.
  • Webbtjänsten lokaliserar raden i listan anpassad och skapar en ny webbplats enligt uppgifterna för den nya klienten använda en anpassad webbplatsdefinition.
  • Webbtjänsten uppdaterar sedan den anpassade listan med information som en länk till den nya webbplatsen.

Ansåg vi andra metoder, som händelsehanterare och visual studio bygger arbetsflöde. SPD tillvägagångssätt ger våra slutanvändare lite mer kontroll över processen. Beviljats, Det finns en hel del C#-kod i denna lösning, men det är insvept inuti en deklarativ arbetsflöde, så vi får några av fördelarna med deklarativa arbetsflöde när du ansluter till tjänsten för att skapa webbplatser.

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.

</slutet>

Prenumerera på min blogg.

Technorati Tags: ,

Integrera SharePoint Designer arbetsflöden med Web Services

Jag har spelat med anpassade åtgärder för SharePoint Designer för en tid (se här för några detaljerade grejer, om som intresserar dig).

I mitt nuvarande projekt, Vi måste göra några ganska tunga lyft och vi vill använda declarative SPD arbetsflöde för att hantera tillhörande affärsprocessen.

Lång historia kort, Detta är fullt möjligt. Jag utökade min Codeplex projekt för att anropa en helper-tjänsten"" och nu kan vi anropa en webbtjänst direkt från ett SPD arbetsflöde.

Här är signaturen:

 offentliga sträng Dispatcher(
        GUID WebID, // Förbi runtime miljön
        GUID SiteID, // Förbi runtime miljön
        sträng ListID, // Förbi RTE (vet inte varför detta är en sträng, inte en GUID)
        int ListItemID, // Förbi RTE.
        sträng XmlMessage) // Passerade av användaren som deklarerats i SPD.

Detta utnyttjar det faktum att vi kan få på viktiga arbetsflödesinformation, som platsen, List-ID, m.m.. Detta är väl dokumenterat i flera förlägger för er intresserade av att skapa dina egna anpassade åtgärder. Tanken är att extrahera XML-strängen som anges av användaren att skicka ett lämpligt förfarande. Kul grejer!

Tyvärr, Detta är naturligtvis en enkelbiljett ner till "Loosey Goosey" anti mönster mark, but it’s better than hitting a brick wall 🙂

Är det en anti mönster om du gör det även om du vet att det är en anti mönster?

Jag hoppas att radbrytas inuti Codeplex detta inom en snar framtid. Om du är intresserad av mig så, ge mig säcken (e-post eller lämna en kommentar) and I’ll be that more enthusiastic about doing it 🙂

</slutet>

Prenumerera på min blogg.

Technorati Tags: ,

SPD arbetsflöde “Samla in Data från en användare”: Ändra genererade Aktivitetsformulär

Jag arbetar på ett projekt som använder fem olika SharePoint Designer arbetsflöden för att hantera vissa dokumentgodkännanden. SPD ger den "samla in datan från en användare" åtgärd så att vi kan uppmana användaren för olika bitar av information, såsom huruvida de godkänner, några kommentarer och kanske fråga vad de hade för middag andra natten.

Formerna är perfekt fungerande. De är bundna till en uppgiftslista som en innehållstyp. De är 100% systemgenererade. Detta är deras styrka och svaghet. Om vi kan leva med standard form, då är vi bra att gå. Men, Vi har inte för mycket kontroll över hur SPD skapar form. Om vi inte gillar det standardbeteendet, Vi behöver tillgripa olika knep att komma runt det (till exempel, att ange prioriteten för en aktivitet).

Jag behövde lämna en länk om formulären uppgift att öppnas Visa egenskaper (DispForm.asxp) för den relaterade artikeln"" i ett nytt fönster. Detta ger ett klick tillgång till metadata för den relaterade artikeln. Detta är vad jag menar:

bild

Tack och lov, Vi kan göra det och det är inte mycket svårt. I stort sett, brand upp SPD, Navigera till den katalog som rymmer Arbetsflödesfiler och öppna ASPX-filen du vill ändra. Dessa är bara klassiska XSL-transformeringen instruktioner och om du har muckade med itemstyle.xsl, Sök eller andra XSL-scenarier, Detta kommer att bli lätt för dig. I själva verket, Jag hittade det är i allmänhet lättare eftersom formuläret genererade är lite lättare att följa jämfört med en webbdel för Sök kärna resultat (eller mardrömslika CWQP).

Självklart, Det finns en stor fallgrop. SPD: s arbetsflödesredigeraren förväntar sig full kontroll över filen. Om du ändrar det, SPD glatt över din ändringar ge rätt uppsättning omständigheter. Jag gjorde två snabba tester för att se hur illa detta skulle kunna få. De båda förutsätter att du har tagit fram ett giltigt SPD arbetsflöde som använder den "samla in datan från en användare" steg.

Testet 1:

  • Ändra aspx-filen för hand.
  • Testa den (Kontrollera att ändringar sparats korrekt och didn't break någonting).
  • Öppna arbetsflödet och lägga till en icke-närstående åtgärd (såsom "logga in historia").
  • Spara arbetsflödet.

Resultat: I detta fall, SPD inte återskapa form.

Testet 2:

  • Gör samma sak som #1 utom direkt ändra "samla in-data från en användare" åtgärd.

Resultat: Detta återskapar formuläret från början, onlineläge ändringarna.

Slutliga anteckningar:

  • Minst två SPD åtgärder skapa formulär här: "Samla in Data från en användare" och "Tilldela att göra objekt". Båda dessa åtgärder’ formulär kan ändras manuellt.
  • Jag har kunnat skapa min länk till dispform.aspx eftersom, i detta fall, relatera artikeln har alltid dess ID inbäddad i den relaterade artikeln URL. Jag fick möjlighet att extrahera den och sedan bygga en <en href> bygger på att tillhandahålla ett klick meta data funktionen. Det är osannolikt att din URL följer denna regel. Det kan finnas andra sätt att få ID för den relaterade artikeln men jag har inte haft att korsa det överbryggar, så jag inte vet om att den andra sidan av klyftan.
  • Jag undersöka inte, men jag skulle inte bli förvånad om det finns något slags mallfil i den 12 registreringsdatafilen som jag kunde ändra för att påverka hur SPD genererar formulären standard (ungefär som vi kan ändra varning mallar).

</slutet>

Prenumerera på min blogg!

Lösning (typ av): Ange prioritet för en aktivitet med SharePoint Designer

Jag har ett affärsscenario såhär:

  • En användare laddar upp ett dokument i ett dokumentbibliotek.
  • Hon väljer en innehållstyp och registrerar metadata som behövs. Ett av fälten meta data är en flagga, "Brådskande".
  • Detta utlöser en SharePoint Designer-arbetsflöde som, bland annat, använder "samla in Data från en användare" åtgärd.

"Samla in Data från en användare" skapar ett objekt i en uppgiftslista som begär godkännande av dokumentet.

Jag behövde för att skapa en vy för listan som visade brådskande begäran om godkännande.

Lösning: Sätt ordet "brådskande:" i titeln på dessa uppgifter.

Jag skulle ha föredragit att ange fältet prioritet direkt. Men, Jag kunde inte göra det av flera skäl:

  1. Samla in data åtgärden ger inte en mekanism för att uppdatera fältet titel (och de ytterligare fält som du vill samla in data).
  2. Den "tilldela en att punkt" har samma problem.
  3. Det är möjligt att infoga ett objekt i en lista (dvs. Infoga ett objekt i listan i direkt) men detta inte en blockerande handling. Det innebär att arbetsflödet inte kommer att vänta för användaren att slutföra uppgiften.

Jag ansåg några metoder innan (Tack och lov) insåg vi kan bara sätta "brådskande" i titeln.

  1. Starta ett arbetsflöde för aktivitetslistan sig så att när en ny aktivitet skapas, det på något sätt korsa referenser tillbaka till dokumentet som startade första arbetsflödet, dra ut den brådskande flaggvärde och uppdatera prioritet som behövs.
  2. Göra något liknande med en händelsemottagare. På Skapa uppgift, hitta den associerade dokumentet och uppdatera prioritet som behövs.
  3. Använda "skapa listobjekt" åtgärder i samband med den "väntan på fältändring" handling och en händelsemottagare. Om vi skapar ett listobjekt, Vi kan ange alla fält vi vill. Använda en händelsemottagare uppdatera originalobjektet när användaren slutför uppgiften och "vänta på fältändring" åtgärd: s villkor är uppfyllt och arbetsflödet skulle gå vidare. (Av någon anledning, Jag hade mer eller mindre bosatte sig på denna strategi innan man beslutar klokt att gå bort för en stund).

Det finns en nackdel med min lösning (Bortsett från det uppenbara faktumet att endast anger texten i rubriken brådskande). Sedan "samla feedback" accepterar endast hårdkodad titel namn, Jag behöver använda två olika samla feedback åtgärder vars enda skillnaden är det hårda kodade titeln.

Men, åtminstone finns det en lösning som inte kräver händelse mottagare eller anpassade SPD åtgärder.

Om någon har löst detta på ett smartare sätt, behaga låta mig veta.

</slutet>

Snabb och enkel: Automatiskt öppna InfoPath-formulär från SharePoint Designer Email

UPPDATERING: Madjur Ahuja påpekar denna länk från en diskussionsgrupp diskussion: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Det är ganska definitiv.

===

Vi vill ofta bädda in hyperlänkar till InfoPath-formulär i e-postmeddelanden skickas från SharePoint Designer arbetsflöden. När användare får dessa e-postmeddelanden, de kan klicka på länken från email och gå direkt till InfoPath-formuläret.

Detta monster URL konstruktion fungerar för 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&Källa = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Ersätta fet röd text med namnet på formuläret, som visas i följande skärmdump:

bild

Observera att det finns en hel del hårdkodade sökvägen i URL:, samt en URL-kodade komponent. Om det är så svårt att översätta till din specifika situation, Prova att vrida på varningar för formulärbiblioteket. Bokför en form och när du får e-post, Visa källan till e-post och du ser allt du behöver inkludera.

Skarpsinniga läsare kanske märker att ovanstående e-kroppen visar också en länk som ansluter direkt till uppgiften via en filtrerad vy. Jag planerar att förklara det närmare i ett kommande inlägg.

</slutet>

Technorati Tags:

MOSS berättar “Åtkomst nekad” Redigera en arbetsflödesuppgift, Men jag har verkligen tillgång

Jag har infört ett arbetsflöde med hjälp av SharePoint Designer på en webbplats som är huvudsakligen skrivskyddad till "NT_AUTHORITYAuthenticated användare" (dvs. alla). Det finns ett formulärbibliotek för ett InfoPath-formulär. Det finns ett associerat arbetsflöde uppgiftslistan också så att när arbetsflödet fungerar, Det kan tilldela aktiviteter till människor.

Jag bryta tillstånd för formulärlistan bibliotek och aktivitet så att alla autentiserade användare kan skapa formulär och uppdatera deras tilldelade aktiviteter.

Jag testa med min låg-privilegier testkonto.

Jag kan fylla ut och spara ett formulär i biblioteket? –> Ja

Kan jag komma åt uppgiften från en e-postlänk? –> Ja

Jag kan se en uppgift länken Redigera arbetsflöde –> Ja

Jag kan klicka på den länken? –> Nej … Permission Denied.

Varför kan jag se en redigera länk som förnekar mig tillstånd när jag klickar på det? Det är inte hur det ska fungera…

Jag går igenom säkerhetskonfigurationen igen, mycket nära. Jag gör det igen. Jag anser att ta bort det här inlägget eftersom jag uppenbarligen inte vet något om säkerhet.

Slutligen, Jag söker Internets. Jag finner detta högst osannolikt MSDN forumtråd: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Affischer verkar föreslå att den enkla handlingen att exportera arbetsflödet till en enhet tallrik kommer att fixa en MOSS-säkerhetsproblem? Jag kan knappt tro jag just skrev som. Jag påminns om South Park avsnittet om den 9/11 konspiration där Stan ber våra Preznit, "Verkligen?" om och om igen.

Så, inget att förlora, Jag eld upp SPD, Högerklicka på arbetsflödet och spara den på min c:\ enhet. Det skulle vara c:\ köra på min laptop. Jag tittar över min axel hela tiden så att ingen kommer att fråga mig, "varför du spara arbetsflödet till din laptop?"

Otroligt, som löser mitt problem. Jag kan redigera uppgift.

Jag nominerar härmed detta är den mest bisarra arbetsflöde Workaround för 2007.

</slutet>

Technorati Tags:

SharePoint Designer, Aktuella objektet “Kodad absolut URL” och HTTPS

Vi vill ofta skicka ett e-postmeddelande som innehåller en hyperlänk till objekt eller dokument som utlöste arbetsflödet. Vi kan använda aktuellt objekt "kodad absolut URL" för detta ändamål. Men, Det tycks alltid använda "http" för URL-protokollet. Om din webbplats körs på HTTPS då det inte kommer att fungera för dig.

bild

Såvitt jag vet, Det finns inget ut av den färdiga lösningen på problemet. Om du behöver använda HTTPS, du har inget av alternativet ruta.

Att lösa det, skapa en anpassad åtgärd som ger en sträng Ersätt funktion som ska användas i arbetsflödet. Alternativt, använda en tredje part verktyg såsom utmärkta paketet här: http://www.codeplex.com/spdwfextensions 🙂

</slutet>

SharePoint Designer Email skickar ???? i ett e-postmeddelande

Forumanvändare be ibland: Varför har SharePoint Designer sätta ???? i min e-post i stället för ett fältvärde?

En anledning detta händer är att den variabel som du hänvisar till är null.

Detta kan hända eftersom du försöker referera till ett fält från den aktuella artikeln"" men användaren trädde aldrig ett värde i det fältet.

<slutet />

Technorati Tags:

Jämför / Test för Tom datum i SharePoint Designer arbetsflöde

Scenariot: I ett arbetsflöde för SharePoint Designer, måste du bestämma om ett date-fält är tomt.

Problem: SPD ger inte en direkt metod för att jämföra datum till något annat än ett datum. Du kan inte skapa ett villkor som denna: "Om [DateField] är lika med Tom".

Lösning: Konvertera datum till en sträng. Använda strängjämförelse för att avgöra om det är blankt.

Skärmdumpar:

Följande skärmdumpar Visa hur man gör detta. I det här scenariot, ett fält på ett objekt, "Miljötillstånd:Först tillåta påminnelsedatum", lämnas och arbetsflödet bränder svar.

bild

bild

Anteckningar:

När jag försökt den här, Jag blev glatt förvånad över att det fungerar. Jag var orolig att SharePoint Designer inte kan tillåta sträng tilldelningen (Variabel:StringReminderDateDate) men det att det.

Jag var också berörda som gör det möjligt, värdet kan vara null och antingen spränga WF under körning eller kanske höja den globala temperaturen 1/2 en viss, men dessa farhågor var ogrundade.

</slutet>

Technorati Tags:

SharePoint Designer anpassade arbetsflödesåtgärden — Observation om <FieldBind Designer typ =”StringBuilder” … />

Bara en snabb iakttagelse att det finns en mycket viktig skillnad mellan dessa två definitioner:

<FieldBind fältet = "InParam1" DesignerType = "StringBuilder" ID = "2" Text = "Input parametern # 1" />

kontra:

<FieldBind fältet = "InParam1" ID = "2" Text = "Input parametern # 1" />

Först visar såhär i SPD:

bild

medan de sistnämnda visar såhär:

bild

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

Iakttagelsen är detta: StringBuilder kan du skapa en sträng (uppenbarligen) genom att blanda ihop teckensträngar och arbetsflödesdata (via den "Lägg till sökning" knappen i det nedre vänstra hörnet). När du använder knappen Lägg till uppslag, den infogar i stället ett token i form"[%variabeln %]". När SharePoint åberopar din anpassade åtgärden, (C#-kod i mitt fall), SharePoint passerar token som sig själv, inte värdet av token. Om du använder standardtypen för designer (den andra typen), SharePoint utökar token och skickar det verkliga värdet för token till åtgärden.

StringBuilder = BAD, standardtyp för designerns = bra.

Självklart, Det är inte vad jag egentligen menar. Bara inte prova och passera en parameter till din anpassade åtgärden när formgivaren skriver = StringBuilder. Använda designer av standardtyp och kedja en StringBuilder att det på framsidan om du behöver för att bygga komplexa strängar i arbetsflödet (vilket är för övrigt exakt vad gör för att skapa en dynamisk ämne för e-post, men det är ett ämne för en annan blogginlägg, har har).

<slutet />