This blog entry is more of an "in the realm of the possible" પ્રવેશ vs. કોંક્રિટ માહિતી.

We have a technical design that calls for us to create a site in a site collection via a manually launched workflow process. મૂળભૂત રીતે, users enter data into a "new customer" custom list and then when they have finished and validated the data entry process, we need to create a site for that customer.

I’m both a big fan of declarative workflow as well as a weak visual studio workflow programmer, so I wanted to meet the requirement using SharePoint Designer.

I plan to write about this in greater detail (and hopefully present to a user group or two in the coming year), but here’s the overall solution:

• Create a custom action that integrates with SPD.
• The custom action allows SPD to invoke a web service and pass it a string of XML.
• Web service locates the row in the custom list and creates a new site as per the data for that new client using a custom site definition.
• Web service then updates the custom list with some information such as a link to the new site.

We considered other approaches, such as event handlers and visual studio based workflow. The SPD approach gives our end users a little more control over the process. Granted, there’s a lot of C# code in this solution, but it’s wrapped inside a declarative workflow, so we get some of the benefits of declarative workflow while hooking into the site-creation 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.

</અંત>

મારા બ્લોગ પર સબ્સ્ક્રાઇબ કરો.

હું કેટલાક સમય માટે શેરપોઈન્ટ ડિઝાઈનર માટે કસ્ટમ ક્રિયાઓ સાથે આસપાસ રમી રહ્યો છું (અહીં જુઓ for some detailed stuff, કે રસ, જો તમે).

મારા વર્તમાન પ્રોજેક્ટ, we need to do some fairly heavy lifting and we want to use declarative SPD workflow to manage the associated business process.

લાંબા વાર્તા ટૂંકી, 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.

Here’s the signature:

 જાહેર સ્ટ્રિંગ મોકલનાર(
        Guid WebID, // Passed by the runtime environment
        Guid SiteID, // Passed by the runtime environment
        સ્ટ્રિંગ ListID, // Passed by the RTE (don't know why this is a string, not a GUID)
        ઈન્ ListItemID, // Passed by the RTE.
        સ્ટ્રિંગ XmlMessage) // Passed by the user as declared in SPD.

This leverages the fact that we can get at important workflow information, like the site, list ID, વગેરે. 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!

દુર્ભાગ્યે, this is obviously a one-way ticket down to "Loosey Goosey" anti-pattern land, પરંતુ તે ઈંટની દિવાલને ફટકારવા કરતાં વધુ સારું છે 🙂

Is it an anti-pattern if you do it even though you know it’s an anti-pattern?

I hope to wrap this inside Codeplex in the near future. If you’re interested in me doing so, give me poke (ઇમેઇલ or leave a comment) અને હું તે કરવા માટે વધુ ઉત્સાહી હોઈશ 🙂

</અંત>

મારા બ્લોગ પર સબ્સ્ક્રાઇબ કરો.

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" ક્રિયા અમે માહિતી વિવિધ બિટ્સ માટે વપરાશકર્તા સંકેત આપી શકે છે કે જેથી, જેમ કે તેઓ તે માન્ય છે કે કેમ તે તરીકે, કેટલીક ટિપ્પણીઓ અને કદાચ અન્ય રાત્રે ડિનર માટે તેમણે શું પૂછો.

The forms are perfectly functional. They are tied to a task list as a content type. તેઓ આ પ્રમાણે છે 100% system-generated. This is their strength and weakness. If we can live with the default form, then we’re good to go. તેમ છતાં, we don’t have too much control over how SPD creates the form. If we don’t like that default behavior, અમે તેને આસપાસ વિચાર વિવિધ યુક્તિઓ આશરો જરૂર (ઉદાહરણ માટે, કાર્ય પર પ્રાયોરિટી સેટીંગ).

હું જુઓ ગુણધર્મો અપ ખોલી છે કે આ કાર્ય સ્વરૂપો પર એક લિંક પ્રદાન કરવા માટે જરૂરી (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:

Thankfully, we can do that and it’s not very hard. Broadly speaking, એસપીડી અપ આગ, 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, શોધ અથવા અન્ય XSL દૃશ્યો, this will be easy for you. હકીકતમાં, પેદા ફોર્મ શોધ કોર પરિણામો વેબ ભાગ સરખામણીમાં અનુસરવા અંશે સરળ છે કારણ કે હું તે સામાન્ય રીતે સરળ મળી (અથવા nightmarish CWQP).

અલબત્ત, 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" પગલું.

પરીક્ષણ 1:

• હાથ દ્વારા ASPX ફાઈલ સુધારો.
• તે ચકાસવા (તમારા ફેરફારો યોગ્ય રીતે સાચવવામાં આવ્યા હતા અને કંઈપણ તોડી ન હતી કે નહીં તે ચકાસવા).
• વર્કફ્લો ખોલો અને બિનસંબંધિત ક્રિયા ઉમેરો (such as "log to history").
• વર્કફ્લો સાચવો.

પરિણામ: આ કિસ્સામાં, એસપીડી ફરી બનાવો ફોર્મ ન હતી.

પરીક્ષણ 2:

• જેવા જ છો #1 except directly modify the "collect data from a user" ક્રિયા.

પરિણામ: આ શરૂઆતથી ફોર્મ ફરીથી બનાવે છે, તમારા ફેરફારો વધારે લેખિત.

અંતિમ નોંધો:

• ઓછામાં ઓછું મુ બે એસપીડી ક્રિયાઓ તો આ જેવા સ્વરૂપો બનાવવા: "Collect Data From a User" and "Assign To Do Item". Both of these actions’ સ્વરૂપો જાતે જ સંશોધિત થઈ કરી શકો છો.
• હું dispform.aspx કરવા માટે મારા લિંક જનરેટ કરવા માટે આપની સમક્ષ હતી કારણ કે, તો આ કેસ માં, the relate item always has its ID embedded in the related item’s URL. I was able to extract it and then build an <એક 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, જેથી હું જો આ ઊંડી ફાટ ઓફ જો આ અન્ય બાજુ કરવા માટે નોંધાયો નહીં, જો ખબર નથી કે.
• હું તપાસ ન હતી, જો આ માં નમૂનો ફાઈલ ઓફ અમુક પ્રકારની ત્યાં છે, જો પરંતુ હું આશ્ચર્ય ન હોઈ હોત 12 હું એસપીડી મૂળભૂત સ્વરૂપો પેદા કેવી રીતે અસર સુધારી શકે છે મધપૂડો (અમે ચેતવણી નમૂનાઓ સંશોધિત કરી શકો છો ખૂબ જેવી).

</અંત>

મારા બ્લોગ પર સબ્સ્ક્રાઇબ કરો!

હું આ જેમ એક બિઝનેસ દૃશ્ય છે:

• એક દસ્તાવેજ લાઇબ્રેરી માટે વપરાશકર્તા અપલોડ દસ્તાવેજ.
• તેણીએ સામગ્રી પ્રકાર પસંદ કરે છે અને જરૂરી મેટા માહિતી પ્રવેશે છે. મેટા માહિતી ક્ષેત્રોમાં એક ફ્લેગ છે, "Urgent".
• આ એક શેરપોઈન્ટ ડિઝાઈનર વર્કફ્લો કે ચાલુ, અન્ય વસ્તુઓ વચ્ચે, uses the "Collect Data from a User" ક્રિયા.

"Collect Data from a User" તે દસ્તાવેજ માટે એક કાર્ય સૂચિ વિનંતી મંજૂરી આઇટમ બનાવે છે.

હું મંજૂરી માટે તાત્કાલિક વિનંતીઓ દર્શાવ્યું કે કાર્ય સૂચિ એક દૃશ્ય બનાવવા માટે જરૂરી.

ઉકેલ: Put the word "URGENT:" into the title of these tasks.

I would have preferred to specify the priority field directly. તેમ છતાં, હું ઘણા કારણોસર તે કરવા માટે અક્ષમ હતું:

1. આ એકત્રિત માહિતી ક્રિયા શીર્ષક કરતાં અન્ય કોઇ પણ ક્ષેત્ર અપડેટ કરવા માટે એક પદ્ધતિ પૂરી પાડે છે નથી (અને તે વધારાના ક્ષેત્રો તમને માહિતી એકત્રિત કરવા માંગો છો, જે માટે).
2. The "assign a to do item" ક્રિયા એ જ સમસ્યા છે.
3. જો તે યાદી માં એક આઇટમ દાખલ કરવા માટે શક્ય છે (દાખલા તરીકે. સીધા કાર્ય સૂચિ માં એક આઇટમ સામેલ) but this not a blocking action. That means that the workflow will not wait for the user to complete that task.

હું પહેલાં થોડા અભિગમ ગણવામાં (thankfully) realizing we could just put "urgent" શીર્ષકમાં.

1. નવી કાર્ય બનાવેલ છે જ્યારે કે જેથી કાર્ય સૂચિ પર જાતે એક વર્કફ્લો પ્રારંભ, તેણે અચાનક પ્રથમ વર્કફ્લો શરૂ જે દસ્તાવેજ સંદર્ભો પાછા પાર, pull out the urgent flag value and update priority as needed.
2. Do something similar with an event receiver. On create of the task, સંકળાયેલ દસ્તાવેજ સ્થિત અને જરૂરી અગ્રતા અપડેટ.
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. (કેટલાક કારણોસર, Wisely જ્યારે માટે દૂર જવામાં નિર્ણય લેતા પહેલાં મારે વધુ કે ઓછું આ અભિગમ પર સ્થાયી થયા હતા).

મારા ઉકેલ માટે ખામી છે (કોરે શીર્ષક માત્ર લખાણ તાકીદ સૂચવે છે કે સ્પષ્ટ હકીકત). Since "collect feedback" માત્ર હાર્ડ કોડેડ શીર્ષક નામો સ્વીકારે, I need to use two different collect feedback actions whose only difference is that hard coded title.

પરંતુ, ઓછામાં ઓછા ઘટના રીસીવરો અથવા વૈવિધ્યપૂર્ણ એસપીડી ક્રિયાઓ જરૂર નથી કે ઉકેલ છે.

કોઈને વધુ હોંશિયાર રીતે આ હલ છે, મને જણાવવા વિનંતી.

</અંત>

અપડેટ: Madjur આહૂજા એક આ લિંક નિર્દેશ સમાચાર ચર્ચા: 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, તેઓ ઇમેઇલ લિંક પર ક્લિક કરો અને ઈન્ફોપાથ ફોર્મ સીધા જઈ શકો છો.

આ રાક્ષસ URL ને બાંધકામ મારા માટે કામ કરે છે:

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

ફોર્મ ના નામ સાથે બોલ્ડ લાલ લખાણ બદલો, નીચેની સ્ક્રીન માં બતાવ્યા પ્રમાણે:

હાર્ડ કોડેડ પાથ ઘણો તે 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, ઇમેઇલ સ્ત્રોત જોવા અને તમે પણ સમાવેશ થાય છે કરવાની જરૂર જોશો.

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.

</અંત>

I’ve implemented a workflow using SharePoint Designer in a site which is mainly read-only to "NT_AUTHORITY\Authenticated Users" (દાખલા તરીકે. બધા). There is a forms library for an InfoPath form. There is an associated workflow tasks list as well so that when the workflow operates, તે લોકો માટે ક્રિયાઓ સોંપી શકે,.

હું કોઇ પણ પ્રમાણિત વપરાશકર્તા સ્વરૂપો બનાવવા અને તેમના સોંપાયેલ ક્રિયાઓ અપડેટ કરી શકો છો કે જેથી સ્વરૂપો પુસ્તકાલય અને કાર્ય સૂચિ માટે પરવાનગી ભંગ.

I test with my low-privileges test account.

હું ભરો અને પુસ્તકાલય માટે એક ફોર્મ પણ સાચવી શકો છો? –> હા

હું એક ઇમેઇલ લિંક ના કાર્ય ઍક્સેસ કરી શકો છો? –> હા

હું એક ફેરફાર કરો વર્કફ્લો કાર્ય લિંક જોઈ શકો છો –> હા

હું કે લિંક પર ક્લિક કરી શકો છો? –> ના … પરવાનગી નકારાઈ.

હું તેના પર ક્લિક કરો ત્યારે શા માટે હું મારી પરવાનગી ઈન્કાર કે સંપાદન લિંક જોઈ શકો છો? That’s not how it’s supposed to work…

હું ફરી સુરક્ષા રૂપરેખાંકન મારફતે જાઓ, very closely. I do it again. હું આ પોસ્ટને કાઢી નાખવાનો ધ્યાનમાં હું ચોક્કસપણે સુરક્ષા વિશે કશું જાણતા નથી કારણ કે.

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

આ પોસ્ટરો ડ્રાઇવ platter માટે વર્કફ્લો નિકાસ ના સરળ અધિનિયમ એક શેવાળના સુરક્ષા સમસ્યાને ઉકેલવા કરશે એવું સૂચન કરવામાં દેખાય? I can hardly believe I just typed that. I’m reminded of the South Park episode about the 9/11 સ્ટાન અમારા Preznit પુછે છે કે જ્યાં કાવતરું, "Really?" over and over again.

તેથી, ગુમાવી કંઇ, હું આગ અપ એસપીડી, વર્કફ્લો પર જમણું ક્લિક કરો અને મારા સી તેને સંગ્રહો:\ 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?"

માનવામાં ન આવે એવી રીતે, that solves my problem. I can edit the task.

હું અહીં ના સૌથી વધુ વિચિત્ર વર્કફ્લો ઉકેલ હોઈ આ નોમિનેટ 2007.

</અંત>

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

જ્યાં સુધી મને ખબર, there is no out of the box solution to this problem. If you need to use HTTPS, you have no out of the box option.

To solve it, create a custom action that provides a string replace function to use in your workflow. Alternatively, use a 3rd party tool such as the excellent package here: http://www.codeplex.com/spdwfextensions 🙂

</અંત>

ફોરમ વપરાશકર્તાઓ ક્યારેક પૂછો: શા શેરપોઈન્ટ ડિઝાઈનર મૂકી નથી ???? તેના બદલે એક ક્ષેત્ર કિંમત મારા ઇમેઇલ માં?

જે તમે સંદર્ભ માટે ચલ નલ છે કારણ કે આ બને એક કારણ છે.

This can happen because you are trying to reference a field from the "current item" પરંતુ વપરાશકર્તા કે ફોર્મ ક્ષેત્રમાં એક મૂલ્ય દાખલ ક્યારેય.

<ઓવરને />

દૃશ્ય લેખ: એક શેરપોઈન્ટ ડિઝાઈનર વર્કફ્લો ઈંચ, you need to determine if a date field is blank.

સમસ્યા: SPD does not provide a direct method for comparing dates to anything other than a date. You cannot create a condition like this: "If [તારીખ ક્ષેત્ર] equals blank".

ઉકેલ: Convert the date to a string. Use string comparison to determine if the date is blank.

સ્ક્રીન શોટ:

The following screen shots show how to do this. આ દ્રશ્ય માં, આઇટમ પર એક ક્ષેત્ર, "Environmental Permits:First Permit Reminder Date", સબમિટ અને જવાબમાં વર્કફ્લો આગ છે.

નોંધો:

હું આ પ્રયાસ કર્યો ત્યારે, I was pleasantly surprised to learn that it works. I was worried that SharePoint Designer might disallow the string assignment (પરિવર્તનશીલ:StringReminderDateDate) પરંતુ તે માટે પરવાનગી આપે કર્યું.

હું પણ તે પરવાનગી આપે છે કે જે સંબંધિત હતી, મૂલ્ય નલ હોઇ શકે છે અને ક્યાં તો રનટાઈમે WF અપ તમાચો અથવા કદાચ વૈશ્વિક તાપમાનમાં વધારો થઈ શકે છે 1/2 ડિગ્રી, પરંતુ તે ચિંતા ખોટી હતી.

</અંત>

આ બે વ્યાખ્યાઓ વચ્ચે એક ખૂબ જ મહત્વપૂર્ણ તફાવત છે તે માત્ર એક ઝડપી નિરીક્ષણ:

<FieldBind Field="InParam1" DesignerType="StringBuilder" Id="2" Text="Input parameter #1"/>

વિરુદ્ધ:

<FieldBind Field="InParam1" Id="2" Text="Input parameter #1"/>

એસપીડી આ જેવી પ્રથમ શો:

બાદમાં આ જેમ બતાવે છે, જ્યારે:

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 🙂

આ અવલોકન છે: StringBuilder તમે શબ્દમાળા બીલ્ડ કરવા માટે મંજૂરી આપો (દેખીતી રીતે) મિશ્રણ માહિતી અને વર્કફ્લો દ્વારા એકસાથે શબ્દમાળા Literals (via the "Add Lookup" નીચલા ડાબા ખૂણે ધ બટન). When you use the Add Lookup button, it inserts a token in the form "[%ટોકન%]". When SharePoint invokes your custom action, (મારા કિસ્સામાં C # કોડ), શેરપોઈન્ટ પસાર-ટોકન પોતે, not the value of the token. If you use the default designer type (-બીજા પ્રકાર), શેરપોઈન્ટ વિસ્તૃત અને તમારા ક્રિયા વાસ્તવિક કિંમત માટે-પ્રતીક ટોકન પસાર.

StringBuilder = BAD, મૂળભૂત ડિઝાઇનર પ્રકાર = GOOD.

અલબત્ત, 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 (જે અકસ્માતે એક ઇમેઇલ ક્રિયા માટે ગતિશીલ વિષય બનાવવા માટે કરે છે બરાબર શું છે, પરંતુ તે બીજા બ્લોગ એન્ટ્રી માટે એક વિષય છે, હર હર).

<ઓવરને />