Deze blog entry is meer van een "in het rijk van de mogelijke" post vs. concrete info.

Wij hebben een technisch ontwerp dat verlangt dat ons een site maken in een siteverzameling via een handmatig gelanceerde workflowproces. In principe, gebruikers invoeren gegevens in een "nieuwe klant" aangepaste lijst en vervolgens wanneer ze hebben voltooid en gevalideerd de data entry-proces, We moeten een site maken voor die klant.

Ik ben zowel een grote fan van declaratieve workflow evenals een zwakke visual studio werkstroom programmeur, dus ik wilde om te voldoen aan de eis met behulp van SharePoint Designer.

Ik ben van plan om te schrijven over dit meer in detail (en hopelijk presenteren aan een gebruikersgroep of twee in het komende jaar), maar hier is de totaaloplossing:

• Een aangepaste actie die met SPD integreert maakt.
• De aangepaste actie kunt EPD beroepen een webservice en een tekenreeks van XML.
• Webservice wordt gezocht naar de rij in de aangepaste lijst en maakt u een nieuwe site volgens de gegevens voor die nieuwe client met behulp van een aangepaste sitedefinitie.
• Webservice vervolgens de aangepaste lijst bijgewerkt met wat informatie zoals een link naar de nieuwe site.

We hebben overwogen andere benaderingen, zoals gebeurtenis-handlers en visuele studio gebaseerd workflow. De SPD-aanpak geeft onze eindgebruikers een beetje meer controle over het proces. Verleend, Er is een heleboel C#-code in deze oplossing, maar het verpakt in een declaratieve workflow, Zo krijgen we enkele van de voordelen van declaratieve workflow terwijl aansluiten in de website-creatie dienst.

Alles wat we nu nodig hebben, is een eenvoudige tool om SPD-workflows automatisch zo gemakkelijk mogelijk te migreren voor visuele studio-workflows en we zullen echt op gas koken 🙂 Ik begrijp dat er mensen zijn die aan dit probleem werken en ik hoop dat ze dat hebben gedaan binnenkort een goed succes.

</einde>

Abonneren op mijn blog.

I been playing rond met aangepaste acties voor SharePoint Designer voor enige tijd (Zie hier voor sommige gedetailleerde stuff, Als dat u interesseert).

In mijn huidige project, We moeten sommige vrij zware werk doen en we willen declaratieve EPD werkstroom gebruiken om de bijbehorende business-proces te beheren.

Lang verhaal kort, Dit is heel goed mogelijk. Ik uitgebreid mijn Codeplex project voor het aanroepen van een "helper-service" en nu we een webservice vanuit een EPD workflow kunt aanroepen.

Hier is de handtekening:

 openbare tekenreeks Dispatcher(
        GUID WebID, // Doorgegeven door de runtime environment
        GUID SiteID, // Doorgegeven door de runtime environment
        tekenreeks ListID, // Doorgegeven door de RTE (weet niet waarom dit een tekenreeks is, niet een GUID)
        int ListItemID, // Doorgegeven door de RTE.
        tekenreeks XmlMessage) // Doorgegeven door de gebruiker, zoals verklaard in SPD.

Dit maakt gebruik van het feit dat we op belangrijke workflowgegevens krijgen kunnen, Als de site, lijst-ID, etc. Dit is goed gedocumenteerd op verschillende plaatsen voor degenen onder u geïnteresseerd in het maken van uw eigen aangepaste acties. Het idee is om de XML-tekenreeks die door de gebruiker aan de verzending van een passende procedure-extract. Fun stuff!

Helaas, Dit is uiteraard een one-way ticket naar beneden naar "Loosey Goosey" Anti-patroon land, maar het is beter dan tegen een bakstenen muur te slaan 🙂

Is het een Antipatroon als je het doet, ook al weet je dat het is een Antipatroon?

Ik hoop dat ik wikkel deze in de nabije toekomst binnen Codeplex. Bent u geinteresseerd in me doen, Geef me zak (E-mail of een reactie achterlaten) en ik zal er zo enthousiast over zijn 🙂

</einde>

Abonneren op mijn blog.

Ik ben bezig met een project dat vijf verschillende SharePoint Designer werk stromen gebruikt voor het afhandelen van bepaalde document goedkeuringen. SPD biedt het "gegevens verzamelen van een gebruiker" actie zodat wij kan de gebruiker voor verschillende stukjes informatie vragen, zoals zij of het goedkeuren, enkele opmerkingen en misschien vragen wat ze hadden voor het diner de andere avond.

De formulieren zijn perfect functioneel. Ze zijn gebonden aan een takenlijst als een inhoudstype. Ze zijn 100% systeem gegenereerde. Dit is hun kracht en zwakte. Als we met het standaardformulier leven kunnen, vervolgens zijn we klaar om te gaan. Echter, We hoeven niet te veel controle over hoe SPD het formulier maakt. Als we niet willen dat standaardgedrag, We moeten hun toevlucht nemen tot verschillende trucs om rond het te krijgen (bijvoorbeeld, prioriteit instellen voor een taak).

Ik nodig had om een link op deze taak vormen die opengesteld de eigenschappen weergeven (DispForm.asxp) van de "gerelateerde item" in een nieuw venster. Dit biedt one-click toegang tot de meta-gegevens van de gerelateerde item. Dit is wat ik bedoel:

Gelukkig, We kunnen dat doen en het is niet erg moeilijk. In het algemeen, vuur opwaarts EPD, Ga naar de map die de werkstroom bestanden huizen en open het ASPX-bestand dat u wilt wijzigen. Deze zijn gewoon klassieke XSL-transformatie instructies en als u hebt mucked over met itemstyle.xsl, Zoek of andere XSL-scenario 's, Dit zal gemakkelijk voor u. Eigenlijk, Ik vond het in het algemeen gemakkelijker omdat de gegenereerde formulier iets gemakkelijker is te volgen ten opzichte van een webonderdeel zoeken kern resultaten (of de nachtmerrie CWQP).

Natuurlijk, Er is één grote valkuil. SPD de workflow editor verwacht volledige controle over dat bestand. Als u het, SPD zal gelukkig overschrijven uw wijzigingen geven het recht van omstandigheden set. Ik heb twee snelle tests om te zien hoe slecht dit kon krijgen. Beiden vereisen dat u een geldig EPD workflow die gebruikmaakt van het "gegevens verzamelen van een gebruiker heb vervaardigd" stap.

Test 1:

• Met de hand het ASPX-bestand wijzigen.
• Test het (Controleer of uw wijzigingen naar behoren zijn opgeslagen en niet om het even wat breken).
• Open de werkstroom en een niet-verwante actie toevoegen (zoals "log naar geschiedenis").
• Opslaan van de werkstroom.

Resultaat: In dit geval, SPD deed niet opnieuw het formulier.

Test 2:

• Hetzelfde doen als #1 Behalve rechtstreeks het "gegevens verzamelen van een gebruiker wijzigen" actie.

Resultaat: Dit maakt de vorm vanaf nul opnieuw, uw wijzigingen stuk.

Definitieve nota 's:

• Ten minste twee EPD acties maakt u formulieren als dit: "Gegevens verzamelen van een gebruiker" en "Toewijzen aan het Item doen". Beide acties’ formulieren kunnen handmatig worden gewijzigd.
• Ik was in staat om mijn link naar dispform.aspx worden gegenereerd omdat, in dit geval, het item koppelen heeft altijd zijn ingesloten in de URL van het bijbehorende item-ID. Ik was in staat om uittreksel op en vervolgens bouwen een <een href> op basis van de functie met één muisklik meta gegevens toegang bieden. Het is onwaarschijnlijk dat uw URL deze regel volgt. Kunnen er andere manieren om de ID van het bijbehorende item maar ik heb niet aan die brug, dus ik weet niet als krijgt aan de andere kant van de kloof.
• Ik onderzoeken niet, maar ik zou niet verbaasd zijn als er is een soort van sjabloonbestand in de 12 component die ik wijzigen kon om te beïnvloeden hoe EPD genereert de standaardformulieren (net als we alert sjablonen kunt wijzigen).

</einde>

Abonneren op mijn blog!

Ik heb een bedrijfsscenario uitzien:

• Een gebruiker uploadt een document naar een documentbibliotheek.
• Ze Hiermee selecteert u een inhoudstype en meta-gegevens invoert als nodig. Een van de gegevensvelden meta is een vlag, 'Urgent'.
• Dit veroorzaakt een SharePoint Designer workflow die, onder andere, Gebruik de "verzamelen gegevens van een gebruiker" actie.

"Gegevens verzamelen van een gebruiker" Hiermee maakt u een item in een takenlijst goedkeuring voor dat document aanvragen.

Ik nodig had om een weergave van de takenlijst die dringende verzoeken om goedkeuring toonde maken.

Oplossing: Zet het woord 'URGENT:" in de titel van deze taken.

Ik had liever direct wilt het veld prioriteit. Echter, Ik was niet in staat om dat te doen om verschillende redenen:

1. De actie gegevens verzamelen voorziet niet in een mechanisme om bij te werken elk veld dan titel (en die extra velden waarvoor u gegevens wilt verzamelen).
2. De "toewijzen een te punt" actie heeft het zelfde probleem.
3. Het is mogelijk om een item in een lijst invoegen (dwz. een item in de lijst met taken rechtstreeks invoegen) maar dit niet een blokkering. Dat betekent dat de werkstroom niet zal wachten voor de gebruiker om deze taak te voltooien.

Ik vond een paar benaderingen voor (Gelukkig) realiseren dat we konden gewoon zetten "urgent" in de titel.

1. Een werkstroom starten in de takenlijst zelf zo dat wanneer een nieuwe taak wordt gemaakt, het Kruis een of andere manier verwijzingen terug naar het document dat de eerste werkstroom heeft gestart, de dringende vlag waarde uitlichten en prioriteit zo nodig bij te werken.
2. Doen iets vergelijkbaars met een gebeurtenis ontvanger. Op maken van de taak, Zoek het bijbehorende document en de update prioriteit zo nodig.
3. Gebruik de "lijstitem maken" actie in combinatie met het "wachten voor veld wijzigen" actie en een gebeurtenis ontvanger. Als we een lijstitem maken, We kunnen alle velden die we willen opgeven. De ontvanger van een gebeurtenis gebruiken om te werken van het oorspronkelijke item wanneer de gebruiker is voltooid voor de taak en het "wachten voor veld wijzigen" van actie voorwaarde zou worden voldaan en de werkstroom zou gaan. (Voor sommige reden, Ik had meer of minder verrekend op deze aanpak alvorens verstandig om weg te lopen voor een tijdje).

Er is een nadeel aan mijn oplossing (Afgezien van het voor de hand liggende feit dat alleen de tekst van de titel geeft aan urgentie). Sinds "feedback verzamelen" accepteert alleen hard gecodeerde titel namen, Ik moet gebruiken twee verschillende feedback verzamelen acties waarvan enige verschil dat hard gecodeerde titel is.

Maar, Er is in ieder geval een oplossing die geen gebeurtenis ontvangers of aangepaste EPD acties vereist.

Als iemand dit in een meer slimme manier opgelost heeft, laat het me weten.

</einde>

UPDATE: Madjur Ahuja wijst erop deze link van een nieuwsgroep discussie: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Het is vrij definitieve.

===

We wilt vaak insluiten hyperlinks naar InfoPath-formulieren in e-mails verzonden vanaf de SharePoint Designer werkstromen. Wanneer gebruikers deze e-mails ontvangen, ze kunnen klik op de link in de e-mail en ga direct naar het InfoPath-formulier.

Deze constructie monster URL werkt voor mij:

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

De vette rode tekst vervangen door de naam van het formulier, zoals in de volgende schermafdruk:

Merk op dat er een heleboel hardcoded pad in dat URL, evenals een gecodeerde URL-onderdeel. Als dit is te moeilijk om te vertalen naar uw specifieke situatie, Probeer het draaien op waarschuwingen voor de formulierbibliotheek. Post een formulier en wanneer u het e-mailbericht, Bekijk de bron van de e-mail en u zult zien dat alles wat die u nodig hebt om op te nemen.

Oplettende lezers kunnen zien dat het bovenstaande e-mail lichaam eveneens wordt weergegeven op een link die rechtstreeks toegang heeft tot de taak via een gefilterde weergave. Ik ben van plan om uit te leggen die in meer detail in een toekomstige post.

</einde>

Ik heb uitgevoerd een workflow in een site die voornamelijk alleen-lezen te NT_AUTHORITYAuthenticated gebruikers"met behulp van SharePoint Designer" (dwz. iedereen). Er is een formulierenbibliotheek voor een InfoPath-formulier. Er is een bijbehorende workflow takenlijst zo goed, zodat wanneer de werkstroom werkt, het kan ook taken toewijzen aan personen.

Ik breken toestemming voor de formulieren bibliotheek en taak lijst zodat elke geverifieerde gebruiker kan formulieren maken en hun toegewezen taken bijwerken.

Ik test met mijn lage-voorrechten testaccount.

Kan vul ik uit en een formulier aan de bibliotheek opslaan? –> JA

Kan ik toegang tot de taak van een e-mail link? –> JA

Ik kan zien een link bewerken werkstroom taak –> JA

Ik kan Klik op deze link? –> NO … Toestemming geweigerd.

Waarom kan ik een koppeling bewerken dat me toestemming ontkent wanneer ik klik op het zien? Dat is niet hoe het heeft verondersteld om te werken…

Ik ga door de beveiligingsconfiguratie opnieuw, zeer nauw. Ik doe het weer. Ik vind dit bericht verwijderen omdat ik uiteraard niet niets over beveiliging weet.

Tot slot, Ik zoek de Internets. Ik vind deze hoogst onwaarschijnlijk MSDN forumthread: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

De posters lijken te suggereren dat de eenvoudige handeling van de workflow exporteren naar een station schotel een beveiligingsprobleem MOSS vast zal? Ik kan nauwelijks geloven dat ik typte die. Ik ben herinnerd aan de South Park-aflevering over de 9/11 samenzwering Stan waar onze Preznit vraagt, "Echt?" over en weer.

Dus, niets te verliezen, Ik brand-up EPD, Klik met de rechtermuisknop op de werkstroom en sla het op mijn c:\ station. Dat zou de c:\ schijf op mijn laptop. Ik ben op zoek over mijn schouder de hele tijd zodat niemand me zal vragen, "waarom u opslaat die werkstroom op uw laptop?"

Ongelooflijk, dat is mijn probleem opgelost. Ik kan de taak bewerken.

Ik benoemen hierbij dit als de meest Bizarre Workflow-oplossing van 2007.

</einde>

Wij willen vaak Stuur een email met een hyperlink naar het item of document dat de werkstroom geactiveerd. We kunnen het gebruik van het huidige item "gecodeerd Absolute URL" voor dit doel. Echter, het lijkt altijd te gebruiken "http" voor de URL-protocol. Als uw site op HTTPS draait zal dan het niet werken voor u.

Voor zover ik weet, Er is geen out van de box oplossing voor dit probleem. Als u wilt gebruiken HTTPS, je hebt geen uit de optie vak.

Te lossen, een aangepaste actie waarmee een tekenreeks vervangen functie om te gebruiken in uw workflow maakt. U kunt ook, Gebruik een 3rd party tool zoals het uitstekende pakket hier: http://www.codeplex.com/spdwfextensions 🙂

</einde>

Forumgebruikers vragen af en toe: Waarom zet SharePoint Designer ???? in mijn e-mail in plaats van een veldwaarde?

Één reden dat dit gebeurt is omdat de variabele waarnaar u verwijst null is.

Dit kan gebeuren omdat u probeert te verwijzen naar een veld van het huidige item"" maar de gebruiker nooit een waarde ingevoerd in dat veld op het formulier.

<einde />

Scenario: In een werkstroom-SharePoint Designer, moet u bepalen als een datumveld leeg is.

Probleem: SPD voorziet niet in een directe methode voor het vergelijken van data naar iets anders dan een datum. U kunt geen maken een aandoening, zoals dit: "If [DateField] is gelijk aan een lege".

Oplossing: De datum converteren naar een tekenreeks. Gebruik string vergelijking om te bepalen als de datum leeg is.

Schermafbeeldingen:

De volgende screenshots tonen hoe te om dit te doen. In dit scenario, een veld in een item, "Milieuvergunningen:Eerste vergunning herinneringsdatum", wordt ingediend en de werkstroom bosbranden in reactie.

Notities:

Toen ik probeerde dit, Ik was aangenaam verrast om te leren dat het werkt. Ik was bang dat SharePoint Designer kan niet toestaan de toewijzingen van tekenreeksen (Variabele:StringReminderDateDate) maar het stond het toe.

Ik was ook bezorgd dat zodat het, de waarde kan worden null en beide opblazen de WF tijdens runtime of misschien verhogen de mondiale temperatuur 1/2 een graad, maar deze zorgen ongegrond waren.

</einde>

Slechts een korte opmerking dat er een heel belangrijk verschil tussen deze twee definities is:

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

versus:

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

De eerste shows zoals dit in het EPD:

terwijl de laatste shows zoals dit:

Ik ben niet zeker hoe nuttig deze screen shots zijn maar ik zet in de inspanning om ze te maken, dus je moet om ze te bekijken 🙂

De observatie is dit: StringBuilder kunt u een tekenreeks bouwen (Uiteraard) door het mengen samen letterlijke tekenreeksen en workflowgegevens (via de "Add Lookup" knop in de linkerbenedenhoek). Wanneer u de knop Opzoeken toevoegen gebruiken, het voegt een token in de vorm"[%token %]". Wanneer SharePoint roept uw aangepaste actie, (C#-code in mijn geval), SharePoint passeert het token zelf, niet de waarde van het token. Als u het standaardtype ontwerper (het tweede type), SharePoint breidt het token en werkelijke waarde van het token worden doorgegeven aan uw actie.

StringBuilder = slecht, standaard ontwerper type = goed.

Natuurlijk, dat is niet wat ik werkelijk bedoel. Gewoon niet proberen en een parameter doorgeven aan uw aangepaste actie wanneer de ontwerper typt = StringBuilder. De ontwerper standaardtype en de keten een StringBuilder ernaar vooraan gebruiken als u nodig hebt om te bouwen van complexe tekenreeksen in uw workflow (dat is overigens precies wat men doet voor het maken van een dynamische onderwerp voor de actie e-mail, maar dat is een onderwerp voor een andere blog entry, Har-har).

<einde />