Hierdie blog inskrywing is meer van 'n "in die realm van die moontlike" inskrywing vs. konkrete inligting.

We have a technical design that calls for us to create a site in a site collection via a manually launched workflow process. Basies, Die users data in 'n "nuwe kliënt" persoonlike lys en dan wanneer hulle klaar is en bekragtig die invoer van die data, ons nodig het om 'n tuiste te skep vir daardie kliënt.

Ek is beide 'n groot fan van verklarende workflow sowel as 'n swak Visual Studio workflow programmeerder, Ek wou die vereiste om te voldoen aan die gebruik van SharePoint Designer.

Ek van plan is om te skryf oor dit in meer besonderhede (en hopelik geskenk aan 'n gebruiker of twee in die komende jaar), maar hier is die algemene oplossing:

• Skep 'n persoonlike aksie wat integreer met SPD.
• Die persoonlike aksie kan SPD 'n web-diens op te roep en gee dit 'n string van XML.
• Web diens gelokaliseer die ry in die persoonlike lys en skep 'n nuwe tuiste soos per die data vir die nuwe kliënt met behulp van 'n persoonlike site definisie.
• Web Updates dan die persoonlike lys met enige inligting wat soos 'n skakel na die nuwe site.

Ons beskou as ander benaderings, such as event handlers and visual studio based workflow. The SPD approach gives our end users a little more control over the process. Granted, daar is 'n baie C # kode in hierdie oplossing, maar dit is toegedraai in 'n verklarende workflow, sodat ons 'n paar van die voordele van 'n verklarende workflow terwyl haak in die werf-skepping.

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.

</einde>

Skryf in op my blog.

Ek het rond speel met 'n persoonlike aksies vir SharePoint Designer vir 'n geruime tyd (Kyk hier vir 'n paar gedetailleerde dinge, as wat jou interesseer).

In my huidige projek, we need to do some fairly heavy lifting and we want to use declarative SPD workflow to manage the associated business process.

Lang storie kort, this is entirely possible. I extended my Codeplex project to invoke a "helper service" and now we can invoke a web service directly from an SPD workflow.

Hier is die handtekening:

 openbare string Planner(
        Guid WebID, // Wat deur die Runtime Environment
        Guid SiteID, // Wat deur die Runtime Environment
        string ListID, // Geslaag deur die RTE (weet nie waarom hierdie is 'n string, nie 'n GUID)
        int ListItemID, // Geslaag deur die RTE.
        string XmlMessage) // Geslaag deur die gebruiker soos verklaar in SPD.

Dit maak gebruik van die feit dat ons kan kry by 'n belangrike workflow inligting, soos die webwerf, lys ID, ens.. This is well documented in several places for those of you interested in creating your own custom actions. The idea is to extract the XML string as provided by the user to dispatch an appropriate procedure. Fun stuff!

Ongelukkig, Dit is natuurlik 'n eenrigting-kaartjie af "Loosey Fernandes" anti-patroon land, but it’s better than hitting a brick wall 🙂

Is dit 'n anti-patroon as jy dit doen, selfs al weet jy dit is 'n anti-patroon?

I hope to wrap this inside Codeplex in the near future. If you’re interested in me doing so, gee my poke (e-pos of laat 'n comment) and I’ll be that more enthusiastic about doing it 🙂

</einde>

Skryf in op my blog.

I’m working on a project that uses five different SharePoint Designer work flows to handle some document approvals. SPD provides the "collect data from a user" aksie, sodat ons kan die gebruiker gevra word vir verskillende stukkies inligting, soos of hulle dit goedkeur nie, 'n paar opmerkings en miskien vra wat hulle vir aandete gehad het die ander aand.

The forms are perfectly functional. They are tied to a task list as a content type. Hulle is 100% system-generated. This is their strength and weakness. If we can live with the default form, then we’re good to go. Egter, we don’t have too much control over how SPD creates the form. If we don’t like that default behavior, ons moet die verskillende truuks te kry om dit (byvoorbeeld, stel van voorkeur op 'n taak).

Ek moes 'n skakel op hierdie taak vorms wat die oog eiendomme oopgemaak om voorsiening te maak (dispform.asxp) van die "verwante item" in a new window. This provides one-click access to the meta data of the related item. This is what I mean:

Gelukkig, we can do that and it’s not very hard. Broadly speaking, vuur op SPD, navigate to the directory that houses the workflow files and open the ASPX file you want to modify. These are just classic XSL transform instructions and if you’ve mucked about with itemstyle.xsl, soek-of ander XSL-scenario's, this will be easy for you. In werklikheid, Ek het dit algemeen makliker te wees sedert die vorm wat gegenereer is ietwat makliker om te volg as in vergelyking met 'n soektog kern resultate web deel (of die nagmerrie CWQP).

Natuurlik, there is one major pitfall. SPD’s workflow editor expects full control over that file. If you modify it, SPD will happily overwrite your changes give the right set of circumstances. I did two quick tests to see how bad this could get. They both presuppose that you’ve crafted a valid SPD workflow that uses the "collect data from a user" stap.

Toets 1:

• Verander die ASPX lêer met die hand.
• Toets dit (seker dat jou veranderings is gered en het nie breek nie).
• Maak die workflow en voeg 'n onverwante aksie (soos "teken in die geskiedenis").
• Stoor die workflow.

Uitslag: In hierdie geval, SPD het nie her-skep die vorm.

Toets 2:

• Doen dieselfde as #1 behalwe direk verander die data in te samel van 'n gebruiker" aksie.

Uitslag: Hierdie her-skep die vorm van nuuts af, Oormekaarskryf jou veranderinge.

Finale Notes:

• Ten minste twee SPD aksies skep vorms soos hierdie: "Versamel data van 'n gebruiker" and "Assign To Do Item". Both of these actions’ vorms kan met die hand verander word.
• Ek was in staat om my skakel tot dispform.aspx te genereer, want, in hierdie geval, the relate item always has its ID embedded in the related item’s URL. I was able to extract it and then build an <a href> based on it to provide the one-click meta data access feature. It’s unlikely that your URL follows this rule. There may be other ways to get the ID of the related item but I have not had to cross that bridge, so ek weet nie of kry aan die ander kant van die kloof.
• Ek het nie ondersoek, maar ek sal nie verbaas wees as daar is 'n soort van template lêer in die 12 korf wat ek kon verander om te beïnvloed hoe SPD die standaard vorms genereer (baie soos ons wakker templates kan verander).

</einde>

Skryf in op my blog!

Ek het 'n besigheid scenario soos hierdie:

• 'N gebruiker uploads 'n dokument aan 'n dokument biblioteek.
• Sy kies 'n tipe inhoud en gaan meta data soos nodig. Een van die meta data velde is 'n vlag, "Urgent".
• Dit veroorsaak 'n SharePoint Designer workflow dat, onder andere, uses the "Collect Data from a User" aksie.

"Collect Data from a User" skep 'n item in 'n taak lys om goedkeuring vir daardie dokument.

Ek nodig het om 'n siening van die taak lys wat gewys het dringende versoeke vir goedkeuring te skep.

Oplossing: Put the word "URGENT:" into the title of these tasks.

I would have preferred to specify the priority field directly. Egter, Ek was nie in staat om dit te doen om verskeie redes:

1. Die data in te samel aksie nie 'n meganisme om 'n ander veld as titel te werk (en die addisionele velde wat jy wil om data in te samel).
2. The "assign a to do item" Die aksie het dieselfde probleem.
3. Dit is moontlik om 'n item in 'n lys te voeg (d.w.z. Voeg 'n item in die taak lys) but this not a blocking action. That means that the workflow will not wait for the user to complete that task.

Ek het gesien hoe 'n paar benaderings voor (gelukkig) realizing we could just put "urgent" in die titel.

1. Begin 'n workflow op die taak lys self so dat wanneer 'n nuwe taak word geskep, dit een of ander manier kruisverwysings terug na die dokument wat begin met die eerste workflow, pull out the urgent flag value and update priority as needed.
2. Do something similar with an event receiver. On create of the task, vind die gepaardgaande dokument en werk prioriteit soos nodig.
3. Use the "create list item" action in conjunction with the "wait for field change" action and an event receiver. If we create a list item, we can specify all the fields we want. Use an event receiver to update the original item when the user completes the task and the "wait for field change" action’s condition would be met and the workflow would proceed. (Vir een of ander rede, Ek het min of meer op hierdie benadering voor wyslik besluit om weg te loop vir 'n rukkie).

Daar is 'n nadeel aan my oplossing (Afgesien van die ooglopende feit dat slegs die teks van die titel dui op die dringendheid). Since "collect feedback" slegs aanvaar die hard gekodeer titel name, I need to use two different collect feedback actions whose only difference is that hard coded title.

Maar, ten minste is daar 'n oplossing wat nie geval ontvangers of persoonlike SPD aksies vereis.

As iemand opgelos in 'n slim manier, laat weet my asseblief.

</einde>

UPDATE: Madjur ahuja punte uit hierdie skakel vanaf 'n nuusgroep bespreking: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. It’s pretty definitive.

===

We often want to embed hyperlinks to InfoPath forms in emails sent from SharePoint Designer workflows. When users receive these emails, hulle kan op die skakel van die e-pos en gaan direk na die Path vorm.

Hierdie monster URL konstruksie werk vir my:

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&Source=http://server.corp.domain.com/sites/departments/Technical%20Services/InformationTechnology/HelpDesk/REC%20REM%20RED%20Forms/Forms/AllItems.aspx&DefaultItemOpen = 1

Vervang die vetgedrukt rooi teks met die naam van die vorm, soos in die volgende kiekie:

Let daarop dat daar is 'n baie harde-gekodeerde pad in die URL, as well as a URL-encoded component. If this is too hard to translate to your specific situation, try turning on alerts for the form library. Post a form and when you get the email, sien die bron van die e-pos en jy alles wat jy nodig het om te sluit sien.

Astute readers may notice that the above email body also shows a link that directly accesses the task via a filtered view. I plan to explain that in greater detail in a future post.

</einde>

Ek het in 'n site wat hoofsaaklik net lees "NT_AUTHORITY bekragtigde gebruikers toegepas word geïmplementeer om 'n werk met 'SharePoint Designer" (d.w.z. almal). There is a forms library for an InfoPath form. There is an associated workflow tasks list as well so that when the workflow operates, dit kan toewys take aan mense.

Ek verbreek toestemming vir die biblioteek en taak lys sodat 'n geverifieerde gebruiker vorms kan skep en werk hulle toegewysde take.

I test with my low-privileges test account.

Kan ek vul en red 'n vorm aan die biblioteek? –> JA

Kan ek toegang tot die taak van 'n e-pos skakel? –> JA

Kan ek sien 'n Edit skakel workflow taak om –> JA

Kan ek op die skakel kliek? –> GEEN … Toestemming geweier.

Hoekom kan ek sien 'n skakel wysig wat my toestemming ontken wanneer ek op? That’s not how it’s supposed to work…

Ek gaan weer deur die sekuriteits verstellings, very closely. I do it again. Ek oorweeg om hierdie pos te skrap omdat ek natuurlik nie weet nie enigiets oor die veiligheid.

Ten slotte, I search the Internets. I find this highly unlikely MSDN forum thread: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Die plakkate vertoon word wat daarop dui dat die eenvoudige daad van die uitvoer van die werksvloei te 'n ry skottel sal 'n MOSS sekuriteit probleem op te los? I can hardly believe I just typed that. I’m reminded of the South Park episode about the 9/11 sameswering waar Stan vra ons Preznit om, "Werklik?" over and over again.

So, niks om te verloor nie, Ek brand SPD, regs-kliek op die workflow en stoor dit in my c:\ drive. That would be the c:\ drive on my laptop. I’m looking over my shoulder the whole time so that no one will ask me, "Hoekom is jy spaar dat workflow na jou laptop?"

Ongelooflik, that solves my problem. I can edit the task.

Ek benoem hiermee die mees bisarre Workflow tydelike oplossing van 2007.

</einde>

We often want to send an email that includes a hyperlink to the item or document that triggered the workflow. We can use current item’s "Encoded Absolute URL" for this purpose. Egter, dit lyk altyd "http te gebruik" for the URL protocol. If your site runs on HTTPS then it will not work for you.

Sover ek weet, there is no out of the box solution to this problem. If you need to use HTTPS, jy het nie uit die boks opsie.

Om dit op te los, create a custom action that provides a string replace function to use in your workflow. Alternatively, gebruik 'n 3de party hulpmiddel soos die uitstekende pakket hier: http://www.codeplex.com/spdwfextensions 🙂

</einde>

Forum gebruikers soms vra: Hoekom nie SharePoint Designer sit ???? in my e-pos in plaas van 'n veld waarde?

Een rede dit gebeur is omdat die veranderlike waarna jy verwys, is van nul.

This can happen because you are trying to reference a field from the "current item" maar die gebruiker nog nooit by 'n waarde in daardie vorm veld.

<einde />

Scenario: In 'n SharePoint Designer workflow, you need to determine if a date field is blank.

Probleem: SPD does not provide a direct method for comparing dates to anything other than a date. You cannot create a condition like this: "If [DateField] equals blank".

Oplossing: Convert the date to a string. Use string comparison to determine if the date is blank.

Screen Shots:

The following screen shots show how to do this. In hierdie scenario, a field on an item, "Environmental Permits:First Permit Reminder Date", is submitted and the workflow fires in response.

Notas:

When I tried this, I was pleasantly surprised to learn that it works. I was worried that SharePoint Designer might disallow the string assignment (Veranderlike:StringReminderDateDate) but it did allow it.

I was also concerned that allowing it, the value might be null and either blow up the WF at runtime or maybe raise the global temperature 1/2 a degree, but those concerns were unfounded.

</einde>

Net 'n vinnige waarneming dat daar 'n baie belangrike verskil tussen hierdie twee definisies:

<FieldBind Veld = "InParam1" Designer Tipe = "String Builder" ID = "2" Text = "invoer parameter # 1" />

teenoor:

<FieldBind Veld = "InParam1" ID = "2" Text = "invoer parameter # 1" />

Die eerste programme soos dit in SPD:

terwyl die laasgenoemde soos hierdie toon:

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 🙂

Die waarneming is dit: StringBuilder kan jy 'n tou te bou (natuurlik) deur die meng die string vasgekodeerde en workflow data (via the "Add Lookup" knoppie in die linkerkantse hoek). When you use the Add Lookup button, it inserts a token in the form "[%teken%]". When SharePoint invokes your custom action, (C # kode in my geval), SharePoint gaan die teken self, not the value of the token. If you use the default designer type (Die tweede soort), SharePoint brei uit die teken en die werklike waarde van die teken te bowe gaan aan jou optrede.

StringBuilder = BAD, standaard ontwerper tipe = GOEIE.

Natuurlik, that’s not what I really mean. Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder. Use the default designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (wat toevallig presies wat 'n mens 'n dinamiese onderwerp te skep vir die e-pos aksie, maar dit is 'n onderwerp vir 'n ander blog inskrywing, is).

<einde />