This blog entry is more of an "in the realm of the possible" færslu vs. steypu upplýsingar.

We have a technical design that calls for us to create a site in a site collection via a manually launched workflow process. Grundvallaratriðum, users enter data into a "new customer" Custom lista og svo þegar þeir hafa lokið og staðfest á færslu gögn ferli, við þurfum að búa til síðu fyrir að viðskiptavinur.

Ég er bæði stór aðdáandi af skilgreiningarþekkingar workflow og veikur Visual Studio workflow forritari, svo ég vildi til að mæta kröfum með SharePoint Designer.

Ég ætla að skrifa um þetta í meiri smáatriðum (og vonandi til staðar til notenda hóp eða tveimur á komandi ári), en hér er almennt lausn:

• Búa til sérsniðnar aðgerðir sem sameinar með SPD.
• The siðvenja aðgerð gerir SPD að beita vefur þjónustu og gefa það a band af XML.
• Vefur þjónusta staðsetur róður í sérsniðnum lista og skapar nýja síðu eins og á gögnum um þessi nýju viðskiptavini með sérsniðna síða skilgreiningu.
• Vefur þjónusta endurnýja þá sérsniðin lista með einhverjum upplýsingum eins og tengil á nýju síðuna.

Við talin önnur aðferðir, such as event handlers and visual studio based workflow. The SPD approach gives our end users a little more control over the process. Granted, það er mikið af C # kóða í þessa lausn, en það er vafinn inn í skilgreiningarþekkingar workflow, þannig að við fá sumir af the hagur af skilgreiningarþekkingar workflow en krókur inn á síðuna-sköpun þjónustu.

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.

</enda>

Gerast áskrifandi að bloggið mitt.

Ég hef verið að leika í kring með sérsniðnum aðgerðir fyrir SharePoint Designer í nokkurn tíma (sjá hér fyrir nokkru ítarlegar efni, ef að hagsmunir þú).

Í núverandi verkefni mitt, we need to do some fairly heavy lifting and we want to use declarative SPD workflow to manage the associated business process.

Langa sögu stutta, 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.

Hér er undirskrift:

 almennings band Dispatcher(
        GUID WebID, // Samþykkt á keyrsluumhverfið
        GUID SiteID, // Samþykkt á keyrsluumhverfið
        band ListID, // Samþykkt á RTE (veit ekki hvers vegna þetta er band, ekki GUID)
        INT ListItemID, // Samþykkt á RTE.
        band XmlMessage) // Samþykkt af notanda sem tilgreind er í SPD.

Þetta notar þá staðreynd að við getum fengið á mikilvægum workflow upplýsingar, eins og síðuna, Listi ID, o.fl.. 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!

Því miður, þetta er augljóslega ein leið miða niður "Loosey Goosey" andstæðingur-mynstur land, but it’s better than hitting a brick wall 🙂

Er það and-mynstur ef þú gerir það jafnvel þó að þú veist það er and-mynstur?

I hope to wrap this inside Codeplex in the near future. If you’re interested in me doing so, gefa mér pota (netfang eða eftir umsögn) and I’ll be that more enthusiastic about doing it 🙂

</enda>

Gerast áskrifandi að bloggið mitt.

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" aðgerð svo að við getum hvetja notandann fyrir mismunandi bita af upplýsingum, svo sem hvort þeir samþykkja það, sumir athugasemdir og kannski spyrja hvað þeir höfðu í kvöldmat um daginn.

The forms are perfectly functional. They are tied to a task list as a content type. Þau eru 100% system-generated. This is their strength and weakness. If we can live with the default form, then we’re good to go. Hins, we don’t have too much control over how SPD creates the form. If we don’t like that default behavior, við þurfum að grípa til ýmissa bragðarefur til að fá í kringum það (til dæmis, setja forgang á verkefni).

Ég þurfti að gefa upp tengil á þessa verkefni form sem opnaðist útsýnið eignir (dispform.asxp) of the "related item" in a new window. This provides one-click access to the meta data of the related item. This is what I mean:

Sem betur fer, we can do that and it’s not very hard. Broadly speaking, skjóta upp 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, leit eða önnur XSL atburðarás, this will be easy for you. Í raun, Ég fann það að vera almennt auðveldara þar sem mynda mynd er nokkuð auðveldara að fylgja samanborið við algerlega leitarniðurstöður vefur hluti (eða nightmarish CWQP).

Auðvitað, 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" stíga.

Próf 1:

• Breyta aspx skrá við hönd.
• Prófa það (staðfesta að breytingar þínar voru rétt vistuð og ekki brjóta neitt).
• Opinn upp workflow og bæta óskyld aðgerð (such as "log to history").
• Vista workflow.

Niðurstaða: Í þessu tilviki, SPD ekki tilvísun til-skapa það form.

Próf 2:

• Gera það sama og #1 except directly modify the "collect data from a user" aðgerð.

Niðurstaða: Þetta aftur skapar form frá grunni, yfir-skrifa breytingarnar.

Final Skýringar:

• Að minnsta kosti tveir SPD aðgerðir skapa form eins og þetta: "Collect Data From a User" and "Assign To Do Item". Both of these actions’ form er hægt að höndunum breytt.
• ÉG var fær til að mynda minn hlekkur til dispform.aspx því, í þessu tilfelli, 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, svo ég veit ekki hvort gerist hinum megin á hyldýpi.
• Ég vissi ekki að rannsaka, en ég myndi ekki vera hissa ef það er einhvers konar skrá sniðmát í 12 Hive, að ég gæti breytt til að hafa áhrif á hvernig SPD býr sjálfgefin eyðublöð (mikið eins og við getum breytt viðvörun sniðmát).

</enda>

Gerast áskrifandi að bloggið mitt!

I have a business scenario like this:

• A user uploads a document to a document library.
• She selects a content type and enters meta data as needed. One of the meta data fields is a flag, "Urgent".
• This triggers a SharePoint Designer workflow that, m.a., uses the "Collect Data from a User" aðgerð.

"Collect Data from a User" creates an item in a task list requesting approval for that document.

I needed to create a view of the task list that showed urgent requests for approval.

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

I would have preferred to specify the priority field directly. Hins, I was unable to do that for several reasons:

1. The collect data action does not provide a mechanism to update any field other than title (and those additional fields for which you want to collect data).
2. The "assign a to do item" action has the same problem.
3. It’s possible to insert an item into a list (i.e. insert an item into the task list directly) but this not a blocking action. That means that the workflow will not wait for the user to complete that task.

I considered a few approaches before (thankfully) realizing we could just put "urgent" in the title.

1. Start a workflow on the task list itself so that when a new task is created, it somehow cross references back to the document that started the first 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, locate the associated document and update priority as needed.
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. (For some reason, I had more or less settled on this approach before wisely deciding to walk away for a while).

There is a drawback to my solution (aside from the obvious fact that only the text of the title indicates urgency). Since "collect feedback" only accepts hard coded title names, I need to use two different collect feedback actions whose only difference is that hard coded title.

En, at least there’s a solution that does not require event receivers or custom SPD actions.

If someone has solved this in a more clever way, please let me know.

</enda>

UPDATE: Madjur Ahuja bendir á þennan tengil frá a ráðstefnu umræða: 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, þeir geta smellt á tengilinn frá tölvupósti og fara beint í Infopath formi.

Þessi slóð skrímsli byggingu virkar fyrir mig:

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

Replace the bolded red text with the name of the form, as shown in the following screenshot:

Note that there is a lot of hard-coded path in that 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, skoða uppruna bréfsins og þú munt sjá allt sem þú þarft til að fela.

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.

</enda>

I’ve implemented a workflow using SharePoint Designer in a site which is mainly read-only to "NT_AUTHORITY\Authenticated Users" (i.e. allir). There is a forms library for an InfoPath form. There is an associated workflow tasks list as well so that when the workflow operates, það getur úthluta verkefnum til fólks.

Ég brjóta leyfi fyrir eyðublöð bókasafn og verkefnalista svo að allir staðfest notandi getur búið til eyðublöð og uppfæra úthlutað verkefnum sínum.

I test with my low-privileges test account.

Get ég að fylla út og vista mynd á bókasafnið? –> YES

Get ég nálgast það verkefni frá netfangatengil? –> YES

Get ég séð Breyta workflow verkefni tengilinn –> YES

Get ég smellt á þessi hlekkur? –> NO … Aðgangi hafnað.

Hvers vegna get ég séð breyta tengilinn sem afneitar mér leyfi þegar ég smelli á það? That’s not how it’s supposed to work…

Ég fara í gegnum öryggi stillingar aftur, very closely. I do it again. Ég tel að eyða þessari færslu því ég augljóslega veit ekki neitt um öryggi.

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

Veggspjöldin virðast vera að leggja til að einfalda athöfn að flytja workflow til a ökuferð fati mun ákveða MOSS öryggi tölublað? I can hardly believe I just typed that. I’m reminded of the South Park episode about the 9/11 samsæri þar Stan er að biðja Preznit okkar, "Really?" over and over again.

Svo, ekkert til að tapa, Ég eldur upp SPD, hægri-smella á workflow og vista það til c minn:\ 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, "why are you saving that workflow to your laptop?"

Ótrúlega, that solves my problem. I can edit the task.

Ég tilnefna hér með þetta að vera mest furðulega Workflow Lausn á 2007.

</enda>

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. Hins, it always seems to use "http" for the URL protocol. If your site runs on HTTPS then it will not work for you.

Eins og langt eins og ÉG vita, there is no out of the box solution to this problem. If you need to use HTTPS, þú hefur ekki út af the kassi valkostur.

Að leysa það, create a custom action that provides a string replace function to use in your workflow. Alternatively, nota 3 aðila tól svo sem framúrskarandi pakka hér: http://www.codeplex.com/spdwfextensions 🙂

</enda>

Forum users occasionally ask: Why does SharePoint Designer put ???? into my email instead of a field value?

One reason this happens is because the variable to which you refer is null.

This can happen because you are trying to reference a field from the "current item" but the user never entered a value into that form field.

<endir />

Atburðarás: Í SharePoint Designer workflow, you need to determine if a date field is blank.

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

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

Skjár skot:

The following screen shots show how to do this. Í þessari atburðarás, reit á hlut, "Environmental Permits:First Permit Reminder Date", er lögð og workflow eldar í svar.

Skýringar:

Þegar ég reyndi þetta, I was pleasantly surprised to learn that it works. I was worried that SharePoint Designer might disallow the string assignment (Variable:StringReminderDateDate) en það gerði leyfa það.

Ég var líka áhyggjur af því að leyfa það, verðmæti gæti verið tómt og annaðhvort blása upp WF á afturkreistingur eða kannski hækka á heimsvísu 1/2 gráðu, en þær grunsemdir voru ástæðulausar.

</enda>

Bara fljótur athugun að það er mjög mikilvægur munur á milli þessara tveggja skilgreininga:

<FieldBind Field = "InParam1" Hönnuður type = "String Builder" Id = "2" Texti = "Inntak breytu # 1" />

á móti:

<FieldBind Field = "InParam1" Id = "2" Texti = "Inntak breytu # 1" />

Fyrstu sýnir eins og þetta í SPD:

á meðan hið síðarnefnda sýnir svona:

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 🙂

Athugun er þetta: StringBuilder gerir þér kleift að byggja upp band (augljóslega) með því að blanda saman band literals og workflow gögn (via the "Add Lookup" hnappinn í neðra vinstra horninu). When you use the Add Lookup button, it inserts a token in the form "[%tákn%]". When SharePoint invokes your custom action, (C # kóða í mínu tilfelli), SharePoint fer táknið sjálft, not the value of the token. If you use the default designer type (The second tegund), SharePoint stækkar táknið og fer raunverulegt verðmæti skapi til aðgerða þína.

StringBuilder = BAD, sjálfgefið hönnuður type = GOOD.

Auðvitað, 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 (sem er tilviljun nákvæmlega hvað maður gerir til að búa til öflugt efni fyrir email aðgerð, en það er fyrirsögn á annan bloggfærslu, Har Har).

<endir />