Dette blogginnlegget er mer av en "i riket av mulige" oppføringen vs. konkret informasjon.

Vi har en teknisk design som krever oss å lage et område i en områdesamling via et manuelt lanserte arbeidsflytprosessen. I utgangspunktet, brukere registrerer data i en "ny kunde" egendefinert liste og deretter når de har ferdig og validert data oppføring prosessen, Vi må lage et nettsted for kunden.

Jeg er både en stor fan av deklarativ arbeidsflyt samt en svak visual studio arbeidsflyt programmerer, så jeg ønsket å møte kravet bruke SharePoint Designer.

Jeg planlegger å skrive om dette nærmere (og forhåpentligvis presentere for en gruppe eller to i de kommende år), men her er den samlede løsningen:

• Opprette en egendefinert handling som integrerer med SPD.
• Den egendefinerte handlingen lar SPD å påkalle en tjeneste og gi det en streng med XML.
• Webtjenesten finner raden i den egendefinerte listen og oppretter et nytt område i dataene for nye klienten bruker en egendefinert områdedefinisjon.
• Webtjenesten oppdaterer deretter den egendefinerte listen med noe informasjon som en kobling til det nye området.

Vi vurderte andre tilnærminger, for eksempel hendelsesbehandlinger og visual studio basert. SPD tilnærmingen gir våre sluttbrukere litt mer kontroll over prosessen. Gitt, Det er mye av C#-kode i denne løsningen, men det er pakket innenfor en deklarativ arbeidsflyt, så vi får noen av fordelene med deklarativ arbeidsflyten mens henge i tjenesten områdeoppretting.

Alt vi trenger nå er et enkelt verktøy for å automatisk migrere SPD-arbeidsflyter så lett vi kan for visualstudio-arbeidsflyter, og vi vil virkelig lage mat med gass 🙂 Jeg forstår at noen folk er der ute som jobber med dette problemet, og jeg håper de har litt god suksess med det snart.

</slutten>

Abonner på bloggen min.

Jeg har spilt med egendefinerte handlinger for SharePoint Designer stund (se her for noen detaljerte ting, Hvis interesse).

I min nåværende prosjekt, Vi må gjøre noen ganske tunge løft og vi ønsker å bruke deklarativ SPD arbeidsflyt til å administrere den tilknyttede forretningsprosessen.

Lang historie kort, Dette er helt mulig. Jeg utvidet min Codeplex prosjekt for å starte en "helper service" og nå kan vi kalle en tjeneste direkte fra en SPD-arbeidsflyt.

Her er:

 offentlig streng Sentralen(
        Guiden WebID, // Vedtatt av runtime miljøet
        Guiden Område-ID, // Vedtatt av runtime miljøet
        streng ListID, // Passerte RTE (vet ikke hvorfor dette er en streng, ikke en GUID)
        Int ListItemID, // Passerte RTE.
        streng XmlMessage) // Vedtatt av brukeren som deklarert i SPD.

Dette utnytter det faktum at vi kan få på viktige arbeidsflytinformasjon, som nettstedet, IDen, osv.. Dette er godt dokumentert på flere steder for de av dere interessert i å opprette din egen egendefinerte handlinger. Ideen er å trekke ut XML-strengen som er angitt av brukeren for å sende en riktig prosedyre. Stæsj!

Dessverre, Dette er åpenbart en enveisbillett ned til "Loosey Goosey" anti-mønster land, men det er bedre enn å treffe en murvegg 🙂

Er det en anti-mønster hvis du gjør det selv om du vet det er en anti-mønster?

Jeg håper å bryte dette inne Codeplex i nær fremtid. Hvis du er interessert i meg gjør det., gi meg dytt (e-post eller Legg igjen en kommentar) og jeg vil være så mer begeistret for å gjøre det 🙂

</slutten>

Abonner på bloggen min.

Jeg arbeider på et prosjekt som bruker fem forskjellige SharePoint Designer arbeidsflyt til å håndtere noen dokumentet godkjenninger. SPD gir "samle data fra en bruker" handlingen slik at vi kan be brukeren om forskjellige informasjonsbiter, som om de godkjenne den, noen kommentarer og kanskje spørre hva de hadde til middag den andre natten.

Skjemaene er perfekt funksjonelle. De er knyttet til en oppgaveliste som en innholdstype. De er 100% systemgenerert. Dette er deres styrke og svakhet. Hvis vi kan leve med standardskjemaet, så er vi gode å gå. Men, Vi har ikke mye kontroll over hvordan SPD oppretter skjemaet. Hvis vi ikke liker denne standardvirkemåten, Vi må ty til ulike triks for å komme rundt det (for eksempel, Angi prioritet for en oppgave).

Jeg måtte gi en link på disse aktivitetsskjemaer som åpnet Visningsegenskaper (DispForm.asxp) av den "relaterte varen" i et nytt vindu. Dette gir Ettklikkstilgang til metadata av den relaterte varen. Dette er hva jeg mener:

Heldigvis, Vi kan gjøre det og det er ikke vanskelig. Stort sett, fyre opp SPD, Naviger til mappen som huser arbeidsflytfilene og åpne ASPX-filen du vil endre. Dette er bare klassiske XSL-transformeringen instruksjoner og hvis du har kastet med itemstyle.xsl, Søk eller andre XSL-scenarier, Dette vil være enkelt for deg. faktisk, Jeg fant det å være generelt enklere siden det genererte skjemaet er noe lettere å følge sammenlignet med en kjerne søkeresultater-webdelen (eller marerittaktige CWQP).

selvfølgelig, Det er en stor fallgruve. Redigeringsprogrammet for SPD arbeidsflyt forventer full kontroll over filen. Hvis du endrer det, SPD lykkelig overskrive din endringer gi høyre sett med omstendigheter. Jeg gjorde to rask tester for å se hvor ille dette kan få. Begge forutsetter at du har laget en gyldig SPD arbeidsflyt som bruker "samle data fra en bruker" Trinn.

Test 1:

• Endre filen ASPX for hånd.
• Test den (Kontroller at endringene var riktig lagret og ikke ødelegge noe).
• Åpne arbeidsflyten og legger til en relatert handling (som "log historie").
• Lagre arbeidsflyten.

Resultatet: I dette tilfellet, SPD ikke gjenopprette skjemaet.

Test 2:

• Gjør det samme som #1 bortsett fra direkte endre "samle data fra en bruker" handling.

Resultatet: Dette oppretter nytt skjema fra bunnen, skrive over endringene.

Siste notater:

• Minst to SPD handlinger oppretter skjemaer som dette: "Samle Data fra en bruker" og "Tilordne til elementet". Begge disse handlingene’ skjemaer kan endres manuelt.
• Jeg kunne generere min link til dispform.aspx fordi, i dette tilfellet, relatere varen har alltid sin ID innebygd i den relaterte varen URL. Jeg klarte å pakke den og deretter bygge en <et href> basert på det å gi funksjonen ett klikk meta data tilgang. Det er usannsynlig at nettadressen følger denne regelen. Det kan være andre måter å få ID av den relaterte varen, men jeg har ikke hatt å krysse denne broen, så jeg ikke vet om får til den andre siden av kløften.
• Jeg undersøke ikke, men jeg ville ikke bli overrasket hvis det er en slags malfil i den 12 strukturen som jeg kunne endre for å påvirke hvordan SPD genererer standardskjemaene (mye som vi kan endre alert maler).

</slutten>

Abonner på bloggen min!

Jeg har et scenario som dette:

• En bruker laster opp et dokument i et dokumentbibliotek.
• Hun velger en innholdstype, og skriver inn metadata etter behov. Ett av feltene for meta-data er et flagg, "Haster".
• Dette utløser en SharePoint Designer-arbeidsflyt som, blant annet, bruker den "samle Data fra en bruker" handling.

"Samle Data fra en bruker" oppretter et element i en oppgaveliste som ber om godkjenning for dette dokumentet.

Jeg trengte å opprette en visning av oppgavelisten som viste presserende anmodninger til godkjenning.

Løsning: Ordet "haster:" i tittelen på oppgavene.

Jeg ville ha foretrukket å angi prioritetsfeltet direkte. Men, Jeg kunne ikke gjøre som av flere grunner:

1. Samle inn data-handlingen gir ikke en mekanisme for å oppdatere andre felt enn tittel (og disse ekstra feltene som du vil samle inn data).
2. Den "Tildel en å element" handlingen har det samme problemet.
3. Det er mulig å sette inn et element i en liste (dvs.. sette inn et element i oppgavelisten direkte) men dette ikke en blokkeringen. Det betyr at arbeidsflyten ikke vil vente for brukeren å fullføre oppgaven.

Jeg har vurdert et par tilnærminger før (Heldigvis) realisere vi kan bare sette "haster" i tittelen.

1. Starte en arbeidsflyt på listen i seg selv, slik at når en ny aktivitet blir opprettet, det noe krysse referanser tilbake til dokumentet som startet første arbeidsflyten, trekke ut haster flaggverdien og oppdatere prioritet etter behov.
2. Gjøre noe lignende med en hendelsesmottaker. Ved oppretting av aktiviteten, Finn den tilknyttede dokumentet og oppdateringen prioritet etter behov.
3. Bruke "lage listeelement" handlingen i forbindelse med den "wait for feltet endre" action og en hendelsesmottaker. Hvis vi oppretter et listeelement, Vi kan spesifisere alle feltene vi vil. Bruk en hendelsesmottaker oppdatere det opprinnelige elementet når brukeren fullfører oppgaven og "vent på feltendring" handlingens tilstand ville bli møtt og arbeidsflyten vil fortsette. (For noen grunn, Jeg hadde mer eller mindre avgjort på denne tilnærmingen før du bestemmer klokt å gange på en stund).

Det er en ulempe til min løsning (bortsett fra det åpenbare faktum at bare teksten i tittelen indikerer haster). Siden "samle tilbakemelding" godtar bare hard kodet tittel navn, Jeg trenger å bruke to ulike samle tilbakemeldinger handlinger som eneste forskjellen er at hard kodet tittelen.

men, minst finnes det en løsning som ikke krever hendelsesmottakere eller egendefinerte handlinger for SPD.

Hvis noen har løst dette i en mer smart måte, gi meg beskjed.

</slutten>

OPPDATERINGEN: Madjur Ahuja påpeker denne linken fra en nyhetsgruppe diskusjon: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Det er ganske definitiv.

===

Ofte ønsker å legge inn hyperkoblinger til InfoPath-skjemaer i e-poster sendt fra SharePoint Designer arbeidsflyter. Når brukere mottar disse e-postene, de kan klikke på linken fra e-posten og gå direkte til InfoPath-skjemaet.

Denne monster URL konstruksjon arbeider for meg:

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

Erstatt uthevet rød teksten med navnet på skjemaet, som vist i følgende skjermbilde:

Note det det er en masse hardkodede banen i URL-adressen, i tillegg til en URL-kodede komponent. Hvis dette er for vanskelig å oversette til din spesielle situasjon., Prøv å slå på varsler for skjemabiblioteket. Legge et skjema og når du får e-post, Vis kilden for e-post og du vil se alt du trenger å inkludere.

Gløgg lesere kan merke at ovennevnte e-kroppen viser også en kobling som får direkte tilgang oppgaven via en filtrert visning. Jeg vil forklare nærmere i en fremtidig innlegg.

</slutten>

Jeg har implementert en arbeidsflyt ved hjelp av SharePoint Designer i et område som er hovedsakelig lese-bare å "NT_AUTHORITYAuthenticated brukere" (dvs.. alle). Det er et skjemabibliotek til et InfoPath-skjema. Det er en også tilknyttede arbeidsflyten oppgaver-listen slik at når arbeidsflyten fungerer, Det kan tilordne oppgaver til personer.

Jeg bryte tilgang for former bibliotek og oppgave liste slik at alle godkjente brukere kan opprette skjemaer og oppdatere tildelte aktiviteter.

Tester med kontoen for lav-privilegier-test.

Jeg kan fylle ut og lagre skjemaer til biblioteket? –> ja

Får jeg oppgaven fra en e-kobling? –> ja

Jeg kan se en redigeringskobling for arbeidsflyten oppgave –> ja

Jeg kan klikke på denne linken? –> nei … Ingen tilgang.

Hvorfor ser jeg en Rediger-kobling som nekter meg tilgang når jeg klikker på det? Det er ikke slik det er ment å fungere…

Jeg går gjennom sikkerhetskonfigurasjonen igjen, svært tett. Jeg gjør det igjen. Jeg vurdere å slette dette innlegget fordi jeg åpenbart ikke vet noe om sikkerhet.

Endelig, Jeg søker Internets. Jeg finner dette svært usannsynlig MSDN forumtråden: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Plakater synes å være antyder at den enkle handlingen å eksportere arbeidsflyten til en stasjon tallerken vil fastsette et MOSS sikkerhetsproblem? Jeg kan knapt tro jeg bare skrevet som. Jeg minnet av South Park-episoden om den 9/11 konspirasjon der Stan ber våre Preznit, "Virkelig?" igjen og igjen.

Så, ingenting å tape, Jeg brann opp SPD, Høyreklikk på arbeidsflyten og lagre den på min c:\ stasjon. Det ville være c:\ kjøre på min laptop. Jeg ser over skulderen min hele tiden slik at ingen vil spørre meg, "Hvorfor er du lagrer arbeidsflyten til bærbare?"

Utrolig, det løser mitt problem. Jeg kan redigere oppgaven.

Jeg nominere herved dette er den mest bisarre arbeidsflyt løsningen for 2007.

</slutten>

Vi ønsker ofte å sende en e-post som inneholder en hyperkobling til elementet eller dokumentet som utløste arbeidsflyten. Vi kan bruke gjeldende element "kodet absolutt URL-adresse" for dette formålet. Men, Det synes alltid å bruke "http" for URL-protokollen. Hvis nettstedet ditt går på HTTPS da det ikke vil fungere for deg.

Så vidt jeg vet, Det er ingen ut av boksen løsningen på dette problemet. Hvis du må bruke HTTPS, du har ingen av alternativet for.

Du kan løse det., opprette en egendefinert handling som gir en streng replace-funksjonen bruke i arbeidsflyten. Alternativt, bruke et 3rd party verktøy som utmerket pakken her: http://www.codeplex.com/spdwfextensions 🙂

</slutten>

Forum brukere spørre til: Hvorfor legger SharePoint Designer ???? i min e-post i stedet for en feltverdi?

En grunn dette skjer er fordi variabelen som du refererer er null.

Dette kan skje fordi du prøver å referere til et felt fra "gjeldende element" men du inn aldri en verdi i dette skjemafeltet.

<slutten />

Scenario: I en arbeidsflyt for SharePoint Designer, du må avgjøre om dato-feltet er tomt.

Problemet: SPD tilbyr ikke en direkte metode for å sammenligne datoene til noe annet enn en dato. Du kan ikke opprette en tilstand som dette: "Hvis [DateField] er lik tomt".

Løsning: Konvertere datoen til en streng. Bruke strengsammenligning for å avgjøre om datoen er tomt.

Skjermbilder:

Følgende skjermbilder viser hvordan du gjør dette. I dette scenariet, et felt i et element, "Miljømessige tillatelser:Først tillate påminnelsesdato", sendes og arbeidsflyten branner svar.

Notater:

Når jeg forsøkt denne, Jeg ble positivt overrasket over å høre at det fungerer. Jeg var bekymret for at SharePoint Designer kan forby streng tildelingen (Variabel:StringReminderDateDate) men det tillater det.

Jeg var også bekymret det slik at det, verdien kan være null og enten sprenge WF under kjøring eller kanskje øke den globale temperaturen 1/2 en grad, men disse bekymringene var ubegrunnet.

</slutten>

Bare en rask observasjon at det er en svært viktig forskjell mellom disse to definisjoner:

<FieldBind feltet = "InParam1" DesignerType = "StringBuilder" ID = "2" Tekst = "Input parameter #1" />

versus:

<FieldBind feltet = "InParam1" ID = "2" Tekst = "Input parameter #1" />

Først viser som dette i SPD:

mens de siste show som dette:

Jeg er ikke sikker på hvor nyttige disse skjermbildene er, men jeg anstrenger meg for å lage dem slik at du må se dem 🙂

Observasjon er dette: StringBuilder kan du bygge en streng (åpenbart) ved å blande sammen strenglitteraler og arbeidsflyt data (via "Legg til oppslag" -knappen i nedre venstre hjørne). Når du bruker du legge oppslagsknappen, det setter et token i skjemaet"[%token %]". Når SharePoint påkaller den egendefinerte handlingen, (C#-kode i mitt tilfelle), SharePoint passerer tokenet selv, ikke verdien til tokenet. Hvis du bruker standard designer type (den andre typen), SharePoint utvider token og sender faktiske verdien til tokenet til handlingen.

StringBuilder = dårlig, standard designer = bra.

selvfølgelig, Det er ikke hva jeg virkelig mener. Bare ikke prøv og sende en parameter egendefinerte handlingen når utformingsverktøyet skriver = StringBuilder. Bruk designer standardtypen og kjeden en StringBuilder den foran hvis du trenger å bygge komplekse strenger i arbeidsflyt (som forresten er akkurat hva man gjør opprette et dynamisk tema for e-handlingen, men det er et emne for en annen bloggpost, har har).

<slutten />