Tämän blogimerkinnän on enemmän "mahdollinen valtakunnassa" merkintä vs. käytännön tietoa.

Meillä tekninen suunnittelu, joka vaatii meitä luoda sivuston sivustokokoelman kautta manuaalisesti aloittaa työnkulkuprosessi. Pohjimmiltaan, tietojen kirjoittamista "uusi asiakas" mukautetun luettelon ja sitten kun on valmis ja vahvistettu tietojen syöttö prosessiin, Meidän täytyy luoda sivuston asiakkaan.

Olen suuri fani deklaratiivinen työnkulun sekä heikko Näkö Ateljee työnkulun ohjelmoija, joten halusin SharePoint Designerilla vaatimuksen täyttämiseksi.

Aion kirjoittaa tästä tarkemmin (ja toivottavasti esittää käyttäjäryhmä tai kaksi ensi vuonna), mutta tässä on kokonaisratkaisua:

• Luo mukautettu toiminto, joka integroituu SPD.
• Mukautetun toiminnon avulla SPD vedota verkkopalvelu ja siirtää se merkkijono XML.
• Web-palvelu etsii rivin mukautetun luettelon ja luo uuden sivuston kuten tiedot kyseisen uuden asiakkaan mukautetun sivuston määrityksen avulla.
• Web-palvelu päivittää sitten mukautetun luettelon joitakin tietoja kuten linkki uuteen sivustoon.

Pidimme muut lähestymistavat, kuten tapahtumakäsittelijät ja visual studio perustuu työnkulku. SPD-lähestymistapa antaa loppukäyttäjille hieman valvoa prosessia. Myönnetty, on paljon C# koodia tässä ratkaisussa, mutta se on kääritty sisällä deklaratiivinen työnkulun, joten saamme joitakin etuja deklaratiivinen työnkulun kun koukkaaminen sivuston luomisen service.

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.

</loppu>

Tilaa blogiin.

Olen pelannut noin kanssa mukautettuja toimintoja SharePoint Designer jonkin aikaa (Katso tässä joitakin yksityiskohtaisia juttuja, Jos sinua kiinnostavan).

Minun nykyisen projektin, Meidän täytyy tehdä joitakin melko raskaita nostoja ja haluamme deklaratiivinen SPD työnkulun avulla voit hallita liittyvä Liiketoimintaprosessi.

Pitkän tarinan lyhyesti, Tämä on täysin mahdollista. I-kirjain avartaa minun Codeplex hanke vedota "helper-palvelu" ja nyt voimme vedota web-palveluun suoraan SPD-työnkulku.

Tässä on allekirjoitus:

 yleiset merkkijono Lähettäjä(
        GUID-tunnus WebID, // Ohi runtime elinympäristö
        GUID-tunnus Sivustotunnus, // Ohi runtime elinympäristö
        merkkijono ListID, // Ohi RTE (En tiedä miksi tämä on merkkijono, ei GUID)
        int ListItemID, // Ohi RTE.
        merkkijono XmlMessage) // Ohi käyttäjän ilmoitettua SPD.

Tämä hyödyntää sitä, että saamme tärkeää työnkulkutiedot, kuten sivuston, Tunnus, jne. Tämä on hyvin dokumentoitu useita paikkoja niille teistä kiinnostunut luomaan oman mukautetut toiminnot. Ajatuksena on purkaa XML-merkkijonona käyttäjä lähettää sopiva menettely. Hupia!

Valitettavasti, Tämä on tietenkin Menolippu alas "Loosey Goosey" Anti kuvio maa, but it’s better than hitting a brick wall 🙂

Onko anti kuvio, jos teet sen, vaikka tiedät se on anti malli?

Toivon paketoida tämän sisällä Codeplex lähitulevaisuudessa. Jos olet kiinnostunut minusta näin, Anna minulle säkissä (Sähköposti tai jätä kommentti) and I’ll be that more enthusiastic about doing it 🙂

</loppu>

Tilaa blogiin.

Olen työskennellyt hanke, joka käyttää viisi SharePoint Designer työnkulkuja käsitellä joitakin asiakirjojen hyväksynnät. SPD antaa "kerätä tiedot käyttäjältä" toimia niin, että voimme Kehota käyttäjää tiedot eri BITS, kuten siitä, voidaanko ne hyväksyä se, joitakin huomautuksia ja pyytää ehkä heillä oli illallinen muiden yö.

Lomakkeet ovat täysin toiminnallinen. Ne ovat sidoksissa tehtäväluettelon sisältötyyppinä. Ne ovat 100% järjestelmän luoma. Tämä on vahvuus ja heikkous. Jos me elämme oletuslomake, sitten me hyvä mennä. Kuitenkin, Meillä ei ole liikaa valvoa miten SPD Luo muodossa. Jos emme pidä tätä oletustoimintaa, Tarvitsemme turvautua eri temppuja saada sen ympärille (esimerkiksi, prioriteetin määrittäminen tehtävän).

Tarvitaan luoda linkin näiden tehtävän lomakkeita, jotka avautuvat ominaisuuksien tarkasteleminen (DispForm.asxp) "liittyvän-nimikkeen" uudessa ikkunassa. Tämä antaa ainoa-click pääsy jotta kohteen metatiedot. Tämä on mitä tarkoitan:

Onneksi, voimme tehdä tämän ja ei ole kovin vaikeaa. Yleisesti ottaen, starttaa ohjelma, Siirry hakemistoon, jossa on työnkulun tiedostot ja avaa ASPX-tiedosto, jota haluat muokata. Nämä ovat vain klassinen XSL-muunnos ohjeet ja jos voit olen mucked kanssa itemstyle.xsl, Etsi tai muut XSL-skenaarioita, Tämä on helppo. Itse asiassa, Se on yleensä helpompaa, koska luotu lomake on hieman helpompi seurata Etsi ydin tulokset web-osan verrattuna löysin (tai nightmarish CWQP).

Tietysti, on yksi tärkeä sudenkuoppa. SPD: n työnkulkueditori odottaa täyden määräysvallan tiedoston. Jos muokkaat, SPD onneksi korvaa muutokset antaa oikeat olosuhteet. Tein kaksi nopeita testejä, kuinka huono tämä voisi saada. Molemmat edellyttävät, että olet muotoillut voimassa SPD työnkulun, joka käyttää "kerää tietoja käyttäjältä" Vaihe.

Testi 1:

• Käsin ASPX-tiedoston muokkaaminen.
• Testata (Varmista, että muutokset tallennettiin oikein ja et rikkoa mitään).
• Avaa työnkulun ja lisää etuyhteydettömille-toiminto (kuten "historia loki").
• Tallenna työnkulku.

Tulos: Tässä tapauksessa, Ohjelma ei luo uudelleen muodossa.

Testi 2:

• Tee sama kuin #1 lukuun ottamatta suoraan muokata "kerätä tietoja käyttäjältä" toiminto.

Tulos: Tämä luo uudelleen lomakkeen alusta, over-Writing muutokset.

Lopullinen muistiinpanot:

• Vähintään kaksi SPD toimia tällä tavoin lomakkeiden luominen: "Kerää tietoja käyttäjältä" ja "Älä kohdetta". Molemmat toimet’ lomakkeita voidaan muokata manuaalisesti.
• Minulla oli mahdollisuus luoda oma linkki dispform.aspx, koska, Tässä tapauksessa, liittyvät nimikkeellä on aina sen ID liittyvän nimikkeen URL-osoitteeseen. Minulla oli mahdollisuus purkaa sitä ja sitten rakentaa <href> sen tarjota yhdellä napsautuksella meta data access-toiminto. On epätodennäköistä, että URL seuraa tätä sääntöä. Voi olla muita tapoja saada kohteen tunnus mutta ei ole tarvinnut sillan yli, joten en tiedä, jos sen kuilun yli toisella puolella saa.
• Et tutkia, mutta olisin ole yllättynyt, jos on olemassa jonkinlainen-mallitiedosto 12 rakenne, jonka muokkaaminen vaikuttaa, kuinka ohjelma luo oletus-lomakkeiden onnistunut (paljon, kuin me muokata ilmoituksen mallit).

</loppu>

Tilaa blogiin!

Minulla on asiat skenaario näin:

• Käyttäjä lataa asiakirjan asiakirjakirjastoon.
• Hän valitsee sisällön tyyppi ja tulee metatietoa tarpeen. Yksi meta-data on lippu, "Kiireellinen".
• Tällöin SharePoint Designer työnkulun että, muun muassa, käyttää "kerätä tietoja kohteesta käyttäjän" toiminto.

"Kerätä tietoja käyttäjältä" Luo kohteen tehtäväluettelon pyytää asiakirjan hyväksyntää.

Minun piti luoda tehtäväluettelon, joka osoitti kiireellisten pyyntöjen hyväksyntä.

Ratkaisu: Sana "kiireellinen:" Nämä tehtävät otsikko.

Olisin halunnut määrittää Prioriteetti-kentän suoraan. Kuitenkin, En voinut tehdä useista syistä:

1. Tietojen kerääminen-toiminto ei tarjoa mekanismi päivittää kaikki muu kuin otsikko (ja ne lisää kentät, joiden haluat kerätä tietoja).
2. "Assign kohtaan" toiminnolla on sama ongelma.
3. On mahdollista lisätä kohteen luetteloon (ts. Kohteen lisääminen tehtäväluetteloon suoraan) mutta tämä ei estää toiminnan. Tämä tarkoittaa, että työnkulun odota käyttäjä suorittaa tehtävän.

Katsoin muutaman lähestymistapoja ennen (Onneksi) ymmärtämättä, voisimme vain laittaa "kiireellinen" otsikko.

1. Aloittaa työnkulun tehtäväluettelo, itse niin, että kun uusi tehtävä luodaan, se jotenkin rajat viittaukset takaisin asiakirjaan, joka aloitti ensimmäinen työnkulun, Vedä kiireellinen lipun arvo ja Päivitä ensisijaisesti tarpeen.
2. Tehdä jotain vastaavaa tapahtuma-vastaanotin. Luo tehtävän, Etsi liittyvää asiakirjaa ja päivityksen prioriteetti tarvittaessa.
3. Käytä "Luo luettelokohde" toimia yhdessä "odota kentän muutosta" toiminta ja tapahtuma-vastaanotin. Jos luomme luettelokohde, voimme määrittää kaikki kentät haluamme. Tapahtuma-vastaanotin avulla päivittää alkuperäisen kohteen, kun käyttäjä suorittaa tehtävän ja "odota kentän muutosta" toiminnon edellytys täyttyisi ja työnkulun menettelee. (Jostain syystä, Oli enemmän tai vähemmän ratkaistaan tämän lähestymistavan päätämme viisaasti kävellä pois jonkin aikaa).

On haittapuoli minun ratkaisu (sen lisäksi ilmeistä että vain teksti otsikko osoittaa kiireellisyyden). Koska kerätä palautetta"" hyväksyy kova koodattu otsikko nimet, Minun täytyy käyttää kaksi eri kerätä palautetta toimenpidettä, jonka ainoa ero on, että kova koodattu otsikko.

Mutta, ainakin on ratkaisu, joka ei vaadi tapahtuman vastaanottajat tai mukautetut SPD toiminnot.

Jos joku on ratkaissut viisaampi tavalla, haluta antaa we osata.

</loppu>

PÄIVITYS: Madjur Ahuja huomauttaa tämän linkin uutisryhmän keskustelun: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Se on melko lopullinen.

===

Me usein haluamme upota hyperlinkkejä InfoPath-lomakkeiden sähköpostit lähetetään SharePoint Designer työnkulut. Koska käyttäjät saavat nämä sähköpostit, he klikkaa linkkiä sähköpostissa ja mene suoraan InfoPath-lomake.

Tämä hirviö URL rakenne toimii minulle:

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

Korvaa Punainen lihavoitu teksti lomakkeen nimi, kuten seuraava kuvakaappaus:

Huomaa, että on paljon URL koodattu polku, sekä URL-koodattu komponentti. Jos tämä on liian vaikea kääntää sinun tilanteeseen, Kokeile ilmoituksia lomakekirjastoa varten. Lähettää lomakkeen ja kun saat sähköpostia, Näytä lähdekoodi sähköposti ja näet kaikki sinun täytyy sisällyttää.

Kokeneet lukijat saatat huomata edellä email laitos osoittaa myös linkki, joka käyttää suoraan tehtävän kautta suodatettua näkymää. Aion selittää tarkemmin tulevan toimeen.

</loppu>

Olen pannut työnkulun SharePoint Designerilla sivusto, joka on lähinnä vain luku-NT_AUTHORITYAuthenticated käyttäjille"" (ts. kaikki). On InfoPath-lomakkeen lomakekirjastoon. On liitetty työnkulun tehtäväluettelo sekä niin, että kun työnkulku toimii, se määrittää tehtäviä henkilöille.

Rikon luvan kirjasto ja tehtävän lomakeluetteloon jotta kuka tahansa anonyymi käyttäjä voi luoda lomakkeita ja päivittää heille varattujen tehtävien.

Olen testin matalan etuoikeus testi tili.

Voi Täytä ja Tallenna lomake kirjastoon? –> Kyllä

Tehtävä käyttää email-linkkiä? –> Kyllä

Näen työnkulun tehtävän linkki –> Kyllä

Voit klikkaa linkkiä? –> Ei … Käyttö estetty.

Miksi näkyvissä Muokkaa-linkkiä, että minua ei anna lupaa kun klikkaa sitä? Joka ei ole miten sen pitäisi toimia…

Käyn läpi suojauksen asetukset uudelleen, hyvin tarkasti. Tee sitä uudestaan. Mielestäni tämä viesti poistetaan koska ilmeisesti tiedä mitään tietoja.

Lopuksi, Etsin Internets. Pidän tätä erittäin epätodennäköistä MSDN foorumi säiettä: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Julisteet näyttävät esittävän, että yksinkertainen teko vietäessä työnkulkua ajaa vati korjaa MOSS ongelma? Voin tuskin uskoa vain kirjoittanut, että. Mieleeni South Park-jaksossa siitä, 9/11 salaliitto jossa Stan pyytää meidän Preznit, "Todella?" uudestaan ja uudestaan.

Niin, mitään menetettävää, Tulen ylös SPD, Napsauta työnkulun ja tallenna se minun c:\ asema. Se on c:\ ajaa minun laptop. Etsin olkapääni yli koko ajan niin, että kukaan Kysy, "Miksi olet säästö työnkulun kannettavaan?"

Uskomattoman, se ratkaisee minun ongelmani. Voin muokata tehtävän.

Täten nimitettävä tämä on Viimeisin outo työnkulun Workaround-lta 2007.

</loppu>

Me usein haluamme lähettää sähköpostia, joka sisältää hyperlinkin kohteen tai asiakirjan, joka käynnisti työnkulku. Käytämme nykyisen kohteen "koodattu absoluuttinen URL-osoite" Tätä varten. Kuitenkin, se tuntuu aina käyttää "http" URL-protokollan. Jos sivustosi toimii HTTPS niin se ei toimi sinulle.

Sikäli kuin tiedän, ei out of the box ratkaisu tähän ongelmaan. Jos haluat käyttää HTTPS, sinulla ei ole ulos ruutuun vaihtoehto.

Ratkaista se, Luo mukautettu toiminto, joka tarjoaa merkkijono korvaa-toimintoa, käyttää työnkulkua. Vaihtoehtoisesti, työkalun kolmas osapuoli, kuten erinomainen paketti tästä: http://www.codeplex.com/spdwfextensions 🙂

</loppu>

Foorumin käyttäjät joskus kysyä: Miksi SharePoint Designer laittaa ???? sähköpostiini kenttäarvon sijasta?

Yksi syy Tämä tapahtuu on muuttuja, johon viittaatte on null.

Tämä voi tapahtua, koska yrität viitata "nykyisen kohteen kenttä" mutta käyttäjä ei koskaan kirjoittaa arvo lomakkeen kenttään.

<Lopeta />

Skenaario: SharePoint Designer-työnkulussa, sinun täytyy määrittää, jos päivämääräkenttä on tyhjä.

Ongelma: SPD ei ole suora menetelmä vertailussa on mitään muuta kuin päivämäärä. Et voi luoda kunnossa kuin tämä: "Jos [DateField] yhtä suuri kuin tyhjä".

Ratkaisu: Päivämäärän muuntaminen merkkijonoksi. Merkkijonon vertailun avulla voit määrittää, jos päivämäärä on tyhjä.

Irtoseinä ammus:

Seuraavat kuvakaappauksia näyttää miten tämä. Tässä tilanteessa, kentän kohde, "Ympäristölupa:Ensin sallia muistutus-Date", toimitetaan ja työnkulun tulipalot vastaus.

Muistiinpanot:

Kun yritin, Olin iloisesti yllättynyt kuullessani, että se toimii. Olin huolissani SharePoint Designerissa voi estää merkkijono tehtävän (Muuttuja:StringReminderDateDate) mutta se mahdollista.

Olin myös huolissaan, jotta se, arvo voi olla null ja joko räjäyttää WF suorituksen tai ehkä nostaa maapallon lämpötilaa 1/2 tutkinto, mutta nämä huolet ovat perusteettomia.

</loppu>

Vain nopeasti havainnointia, on erittäin tärkeä ero näiden kahden määritelmät:

<FieldBind kentän = "InParam1" DesignerType = "StringBuilder-kohteen" Tunnus = "2" Tekstin = "Input parametrin # 1" />

versus:

<FieldBind kentän = "InParam1" Tunnus = "2" Tekstin = "Input parametrin # 1" />

Ensimmäinen näyttää tällaiselta SPD:

Kun jälkimmäinen näyttää tällaiselta:

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 🙂

Huomautus on tämä: StringBuilder-kohteen avulla voit muodostaa merkkijonon (tietenkin) sekoittamalla yhdessä merkkijonoliteraalit ja työnkulun tiedot (kautta "Lisää haku" vasemmassa alakulmassa-painiketta). Kun käytät Lisää valinta-painiketta, se lisää tunnussanoma muodossa"[%tunnussanoma %]". Kun SharePoint käynnistää mukautetun toiminnon, (C# minun tapauksessa koodi), SharePoint kulkee itse tunnussanoma, tunnuksen arvo. Jos käytät Design oletustyyppi (toinen tyyppi), SharePoint laajentaa tunnussanoman ja välittää todellinen arvo tunnussanoman toimi.

StringBuilder-kohteen = BAD, Oletus suunnittelutyökalun tyyppi = hyvä.

Tietysti, se ei ole mitä todella tarkoitan. Älä kokeile ja välittää parametri mukautetun toiminnon, kun suunnittelija kirjoittaa = StringBuilder. Käyttää Design oletustyyppi ja ketjun StringBuilder sen edessä, jos sinun täytyy rakentaa monimutkaisia jouset työnkulkuun (jotka muuten on juuri sellainen luoda dynaamisen aihe sähköposti-toiminto, mutta tämä on toinen blogimerkinnän aihe, har har).

<Lopeta />