Tohto blogu vstupe je viac "v ríši prípadné" položka vs. konkrétne info.

Máme technického návrhu, ktorý volá na nás vytvoriť lokalitu v kolekcii lokalít cez ručne spustený pracovného postupu. V podstate, používatelia zadávajú údaje do "nového zákazníka" vlastný zoznam a potom keď majú hotové a overené procesu vstupu údajov, Musíme vytvoriť lokalitu pre tohto zákazníka.

Som veľký fanúšik deklaratívne toku činností, ako aj slabé visual studio workflow programátor, tak som chcel splniť požiadavku použitie SharePoint Designer.

Mám v pláne písať o tom podrobnejšie (a dúfajme, že predstavujú pre skupinu používateľov alebo dva v budúcom roku), ale tu je celkového riešenia:

• Vytvoriť vlastnú akciu, ktorý integruje s JPD.
• Vlastná akcia umožňuje JPD vyvolať webovú službu a preniesť ho reťazec XML.
• Webová služba vyhľadá riadok v zozname vlastné a vytvorí novú lokalitu podľa údajov pre nový klienta pomocou vlastné stránky definície.
• Webová služba potom aktualizuje vlastný zoznam niektoré informácie, ako napríklad prepojenie na nové stránky.

Domnievame, že iné prístupy, napríklad obsluhy udalostí a programu visual studio založené workflow. SPD prístup dáva našich koncových užívateľov o niečo väčšiu kontrolu nad procesom. Udelené, existuje veľa kódexu C# v tomto roztoku, ale je zabalená vo vnútri deklaratívne tok činností, tak sme sa dostať niektoré z výhod, deklaratívne toku činností pri Bodné do tvorby lokality služby.

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.

</koniec>

Vyberajte môj blog.

Bol som hrať s vlastné akcie SharePoint Designer nejakú dobu (pozri tu pre niektoré detailné veci, Ak vás to zaujíma).

V môj súčasný projekt, musíme urobiť niektoré docela zdvíhanie ťažkých bremien a chceme používať deklaratívnu SPD toku činností na spravovanie procesu pridruženej organizačnej.

Dlhý príbeh krátky, to je úplne možné. Som predĺžil môj projekt Codeplex vyvolať Pomocníka služby"" a teraz môžeme odvolávať webovej služby priamo z tok SPD.

Tu je podpis:

 verejné reťazec Dispečer(
        Identifikátor GUID WebID, // Prešiel runtime prostredie
        Identifikátor GUID SiteID, // Prešiel runtime prostredie
        reťazec ListID, // Prešiel RTE (Neviem prečo je to reťazec, nie GUID)
        int ListItemID, // Prešiel RTE.
        reťazec XmlMessage) // Schválil používateľ deklarované v SPD.

To využíva skutočnosť, že môžeme dostať informácie o toku činností dôležité, rovnako ako stránky, Identifikácia zoznamu, atď. To je dobre zdokumentovaný v niekoľkých miestach pre tých z vás záujem vytvoriť svoj vlastný vlastné akcie. Myšlienka je extrahovať reťazec XML, ako je poskytovaná používateľ odoslaním vhodný postup. Zábavné veci!

Bohužiaľ, to je samozrejme jednosmerný lístok na "Loosey vystrašený" Anti-Pattern pôdy, but it’s better than hitting a brick wall 🙂

Je to anti-pattern, ak si to, aj keď viete, že je to anti-pattern?

Dúfam, že to v blízkej budúcnosti zalomí Codeplex. Ak vás zaujíma ma pritom, Daj mi grófov (e-mailom alebo zanechať komentár) and I’ll be that more enthusiastic about doing it 🙂

</koniec>

Vyberajte môj blog.

Som pracoval na projekte, ktorý používa päť rôznych pracovných tokov SharePoint Designer zvládnuť niektoré schválení dokument. SPD poskytuje "zhromažďovanie údajov od používateľa" akcie tak, aby sme môže používateľa vyzvať pre rôzne kúsky informácií,, ako napríklad, či schvália, niektoré komentáre a možno pýtať, čo mali na večeru v noci.

Formuláre sú dokonale funkčné. Sú viazané na zozname úloh ako typ obsahu. Sú 100% vygenerované systémom. To je ich sila a slabosť. Ak môžeme žiť s predvolený formulár, potom sme dobré ísť. Avšak, Nemáme príliš veľa kontrolu nad ako JPD vytvorí formulár. Ak sa nám nepáči, že predvolené správanie, Musíme sa uchýliť k rôzne triky sa dostať okolo neho (napríklad, Nastavenie priority na úlohu).

Potreboval som sa uviesť odkaz na tieto úlohy formuláre, ktoré otvoril Zobraziť vlastnosti (dispform.asxp) "súvisiace položky" v novom okne. To ponúka jeden-cvaknúť prístup k meta dáta súvisiace položky. Je to, čo mám na mysli:

Našťastie, môžeme to urobiť, a nie je to veľmi ťažké. Všeobecne povedané, oheň SPD, Prejdite do adresára, ktorý domy toku súbory a otvorte ASPX súbor, ktorý chcete upraviť. Toto sú len klasické pokyny transformácie XSL a ak ste už výmeny, zložené s itemstyle.xsl, vyhľadávanie alebo iných scenárov XSL, to bude pre vás ľahké. v skutočnosti, Našiel som to je všeobecne ľahšie, pretože vygenerovaný formulár sa trochu ľahšie nasledovať v porovnaní s webovej časti základných výsledkov vyhľadávania (alebo strašidelný CWQP).

samozrejme, tam je jeden hlavný pascu. JPD je tok činností editora očakáva, že plnú kontrolu nad súboru. Ak si to zmeniť, SPD šťastne prepísať vaše zmeny dávajú právo stanoviť okolnosti. Urobil som dva rýchle testy, aby zistili, ako zlé to mohlo dostať. Obaja predpokladajú, že už vytvorený platné SPD pracovný postup, ktorý používa "zhromažďovanie údajov od používateľa" krok.

Test 1:

• Ručne upraviť súbor ASPX.
• Vyskúšať (Skontrolujte, či vaše zmeny boli riadne uložené a nenarušili nič).
• Otvoriť pracovný postup a pridať nesúvisiace akciu (ako "denník História").
• Uložiť pracovný postup.

Výsledok: V tomto prípade, SPD nie re-vytvoriť formulár.

Test 2:

• To isté ako #1 s výnimkou priamo upraviť "zhromažďovanie údajov od používateľa" Akcia.

Výsledok: Re-vytvorí formulár od nuly, nadmernej-písanie zmeny.

Záverečné poznámky:

• Aspoň dve opatrenia JPD vytvárať formuláre takhle: "Zhromaždiť údaje od používateľa" a "Priradiť položku". Obe tieto akcie’ formuláre je možné manuálne upraviť.
• Som bol schopný vytvoriť môj odkaz na dispform.aspx, pretože, v tomto prípade, položka relate má vždy svoje ID vložené do príbuznej položky URL. Bol som schopný extrahovať, a potom budovať <a href> základe poskytnúť jeden-cvaknúť meta dát funkcie prístupu. Je nepravdepodobné, že vaša adresa URL takto toto pravidlo. Môžu existovať iné spôsoby, ako získať identifikátor súvisiacej položky, ale nemuseli cez most, tak neviem, či sa dostane na druhej strane priepasť.
• I didn't vyšetrovať, ale já bych nemal byť prekvapený, keď tam je nejaký druh súboru 12 podregister, ktorý mohol zmeniť ovplyvniť ako JPD vytvára tieto predvolené formuláre (rovnako ako môžeme upraviť upozornenie šablóny).

</koniec>

Vyberajte môj blog!

Mám obchodné scenáre takhle:

• Užívateľ obrázky dokumentu do knižnice dokumentov.
• Ona vyberie typ obsahu a zadá meta údaje podľa potreby. Jedno z polí údajov meta je vlajka, "Naliehavé".
• To vyvoláva pracovného postupu programu SharePoint Designer,, okrem iného, používa "zhromaždiť údaje od používateľa" Akcia.

"Zhromaždiť údaje od používateľa" vytvorí položku v zozname úloh požadujúce schválenie dokumentu.

Som potreboval na vytvorenie zobrazenia zoznamu úloh, ktorý ukázal naliehavej žiadosti o schválenie.

Roztok: Dal slovom "súrne:" do hlavy týchto úloh.

Radšej by som určiť prioritné oblasti priamo. Avšak, Bol som schopný to urobiť z viacerých dôvodov:

1. Akcie zhromažďovanie údajov neposkytuje mechanizmus na aktualizáciu ľubovoľné pole ako hlava (a tie ďalšie polia, ktoré chcete zhromaždiť údaje).
2. "Priradenie k tovaru" akcia má rovnaký problém.
3. Je možné vložiť položku do zoznamu (tj. Vložiť položku do zoznamu úloh priamo) ale to nie je blokovanie akcia. To znamená, že tok činností nepočká pre užívateľa k dokončenie úlohy.

Som za niekoľko prístupov pred (Našťastie) si uvedomil, sme jednoducho dať "naliehavé" v názve.

1. Spustenie toku činností v zozname úlohy sama tak, že keď sa vytvorí nová úloha, to nejako cez odkazy späť do dokumentu, ktorý začal prvý pracovný postup, Vytiahnite naliehavé príznak hodnota a aktualizovať prioritné potreby.
2. Niečo podobné s príjemca udalosti. Na vytvorenie úlohy, Vyhľadajte súvisiacom dokumente a aktualizáciu prioritné potreby.
3. Pomocou "vytvoriť položku zoznamu" akcie v spojení s "čakať na zmenu poľa" akcie a podujatia prijímač. Budeme-li vytvoriť položku zoznamu, môžeme zadať všetky polia, ktoré chceme. Príjemca udalosti sa používa na aktualizáciu pôvodnej položky, keď používateľ dokončí úlohy a "čakať na zmenu poľa" Akcia je podmienka by splnená a pracovného postupu by pokračovať. (Z nejakého dôvodu, Mal som viac či menej usadil na tento prístup ako múdro rozhodne odísť na chvíľu).

Tam je nevýhodou moje riešenie (Okrem zjavné skutočnosti, že iba text titulu označuje naliehavosť). Od "zbierať spätnú väzbu" prijíma len pevne zakódované názov názvy, Musím používať dve rôzne zbierať spätnú väzbu akcie, ktorých jediný rozdiel je, že pevný kódovaný názov.

ale, aspoň nie je riešenie, ktoré nevyžaduje žiadne podujatie správcov konkurznej podstaty alebo vlastné SPD akcie.

Ak niekto vyriešil to múdrejší spôsobom, Dajte mi prosím vedieť.

</koniec>

AKTUALIZÁCIA: Madjur Ahuja poukazuje na to, tento odkaz od diskusné: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. To je docela konečné.

===

Často chceme vložiť hypertextové odkazy na formuláre programu InfoPath v e-maily odoslané z pracovné postupy programu SharePoint Designer. Keď používatelia dostávať tieto e-maily, môžete kliknúť na odkaz z e-mailu a ísť priamo do formulára programu InfoPath.

Toto monštrum URL stavebné práce pre mňa:

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&Zdroj = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Tučný červený text nahraďte názov formulára, ako je znázornené na nasledujúcom obrázku:

Všimnite si, že existuje veľa hard-kódovaný cestu v URL, rovnako ako súčasť URL-kódovaný. Ak je to príliš ťažké preložiť do vašej konkrétnej situácii, Skúste zapnúť upozornenia pre knižnice formulárov. Odoslať formulár a keď sa dostanete e-mail, Zobraziť zdroj e-mailu a budete vidieť všetko, čo budete musieť zahrnúť.

Bystrý čitatelia si všimnúť, že vyššie uvedený e-mail telo tiež ukazuje odkaz, ktorý priamo pristupuje úlohy prostredníctvom filtrované zobrazenie. Mám v pláne to vysvetliť podrobnejšie v budúcnosti post.

</koniec>

I realizované toku činností pomocou programu SharePoint Designer v mieste, ktoré je prevažne len na čítanie "NT_AUTHORITYAuthenticated užívateľov" (tj. Všetci). Tam je knižnice formulárov programu InfoPath. Nie je priradený pracovný postup zoznamu úloh rovnako tak, že keď pôsobí toku činností, môžete priradiť úlohy používateľom.

Zlomiť povolenie formulárov knižnice a úloha zoznamu tak, že každý overený užívateľ môžete vytvoriť formuláre a aktualizovať svoje pridelené úlohy.

Som test mojej nízke-oprávnenia testovacieho konta.

Môžete vyplniť a uložiť formulár do knižnice? –> áno

Môžete prístup úlohy z e-mailového spojenia? –> áno

Zobraziť prepojenie úlohy toku činností –> áno

Môžete kliknú toto prepojenie? –> nie … Prístup bol odmietnutý.

Prečo môžete vidieť odkaz upraviť, ktorý popiera mi povolenie, keď kliknete na to? To je, nie ako to má fungovať…

Idem cez konfiguráciu zabezpečenia znova, veľmi úzko. Urobiť znovu. Som za zmazanie tento príspevok pretože samozrejme Nechcem know anything o bezpečnosti.

Nakoniec, Hľadať internety. Považujem tento vysoko nepravdepodobné MSDN fórum vlákno: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Plagáty zdajú byť naznačuje, že prostý akt exportu pracovného postupu na tanieri disk opraviť MOSS bezpečnostným problémom? Môžu len ťažko uveriť, len napísal, že. Som pripomenul epizódy South Park o 9/11 sprisahania kde Stan je otázkou našej Preznit, "Naozaj?" znova a znova.

Takže, čo stratiť, Som oheň do SPD, pravým-kliknite na pracovný postup a uložte ho do mojej c:\ disk. To by bolo c:\ disk na mojom notebooku. Hľadám cez rameno celú dobu tak, že nikto sa ma, "prečo ste ukladanie tok činností pre váš notebook?"

Neuveriteľne, to vyrieši môj problém. Môžete upraviť úlohu.

Týmto by som to byť najviac bizarné Workflow riešenie z vymenovať 2007.

</koniec>

Sme sa často chcú poslať e-mailom, ktorá obsahuje hypertextové prepojenie na položku alebo dokument, ktorý spustil tok činností. Môžeme použiť aktuálnu položku "kódovaná absolútna adresa URL" na tento účel. Avšak, vždy zdá sa používať "http" URL protokolu. Ak vaše stránky beží na HTTPS, potom to nebude pracovať pre vás.

Pokiaľ viem, Neexistuje žiadny z box riešenie tohto problému. Ak potrebujete použiť HTTPS, nemáte žiadne z možnosti.

To vyriešiť, vytvoriť vlastnú akciu, ktorá poskytuje reťazec nahradiť funkciu použiť v pracovnom postupe. Alternatívne, nástrojom 3rd strana napríklad vynikajúci balík tu: http://www.codeplex.com/spdwfextensions 🙂

</koniec>

Príležitostne požiadať fórum užívateľov: Prečo program SharePoint Designer dať ???? do mojej e-mail namiesto hodnoty poľa?

Jeden dôvod, prečo to stane je pretože premenná na ktoré odkazujete má hodnotu null.

To sa môže stať, pretože sa snažíte referenčné pole "aktuálnej položky" ale užívateľ nikdy nadobudla hodnotu tohto poľa formulára.

<koniec />

Scenár: V pracovného postupu programu SharePoint Designer, musíte určiť, ak je dátum pole prázdne.

Problém: SPD neposkytuje priamu metódu pre porovnávanie dátumov nič iného ako dátum. Nemôžete vytvoriť stav takhle: "Ak [DateField] rovná sa prázdne".

Roztok: Previesť dátum na reťazec. Použiť reťazec porovnanie či dátum je prázdny.

Obrazovke zábery:

Nasledujúce snímky obrazoviek Ukázať, ako to urobiť. V tomto scenári, pole položky, "Environmentálnych povolení:Prvé povolenie na pripomenutie dátumu", predkladá a workflow požiare v reakcii.

Poznámky:

Keď som sa snažil to, Bol som príjemne prekvapený, že to funguje. Bála som sa, že program SharePoint Designer môže zakázať priradenie reťazec (Premenná:StringReminderDateDate) ale to robil to.

Bol som tiež týka, že umožňuje, hodnota môže byť null a buď vyhodiť WF v runtime alebo možno zvýšenie globálnej teploty 1/2 stupeň, ale tieto obavy neboli neopodstatnené.

</koniec>

Len rýchly pozorovanie, že je veľmi dôležitý rozdiel medzi tieto dve definície:

<FieldBind pole = "InParam1" DesignerType = "StringBuilder" ID = "2" Text = "Vstupný parameter #1" />

oproti:

<FieldBind pole = "InParam1" ID = "2" Text = "Vstupný parameter #1" />

Prvý ukazuje, ako je to v SPD:

kým posledne ukazuje ako je tento:

Nie som si istý, aké užitočné sú tieto snímky obrazovky, ale vynaložil som úsilie na ich vytvorenie, takže si ich musíte pozrieť 🙂

Pozorovanie je to: StringBuilder vám umožňuje vytvoriť reťazec (Samozrejme) zmiešaním spolu reťazcové literály a toku údajov (prostredníctvom "pridať vyhľadávacie" tlačidlo v ľavom dolnom rohu). Ak použijete tlačidlo Pridať vyhľadávanie, Vloží prejav v podobe"[%token %]". Keď SharePoint vyvolá vlastnej akcie, (C# kód v mojom prípade), SharePoint prechádza token sám, nie hodnotu tokenu. Ak používate predvolený typ dizajnér (Druhý typ), SharePoint token sa rozširuje a prechádza skutočná hodnota tokenu pre Vašu akciu.

StringBuilder = zlý, predvolené návrhár typ = dobré.

samozrejme, to nie je to, čo som naozaj mysli. Len Nesnažte sa odovzdať parameter svoje vlastné akcie, keď návrhár typ = StringBuilder. Použiť predvolený typ návrhár a reťazec StringBuilder to vpredu, ak potrebujete vytvoriť zložité struny v pracovnom postupe (ktoré mimochodom je presne to, čo jeden vytvoriť dynamické predmet činnosti e-mail, ale to je predmetom iného blogu, Har har).

<koniec />