This blog entry is more of an "in the realm of the possible" entry vs. concrete info.

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.

تنها چیزی که اکنون به آن نیاز داریم یک ابزار آسان برای انتقال خودکار گردش‌های کاری SPD به آسانی تا جایی که می‌توانیم برای گردش‌های کاری استودیو تصویری داریم و ما واقعاً با گاز آشپزی می‌کنیم. چند موفقیت خوب با آن به زودی.

</پایان>

مشترک شدن در وبلاگ من.

من بازی در اطراف با اقدامات سفارشی برای طراح شیرپوینت برای برخی از زمان (اینجا را ببینید برای برخی از مسائل مفصل, در صورتی که منافع شما).

در پروژه کنونی من, 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.

در اینجا امضا:

 عمومی رشته اعزام کننده(
        GUID WebID, // محیط زمان اجرا به تصویب رسید
        GUID SiteID, // محیط زمان اجرا به تصویب رسید
        رشته ListID, // RTE به تصویب رسید (نمی دانم چرا این رشته است, نه یک GUID)
        اعضای هیات ListItemID, // RTE به تصویب رسید.
        رشته XmlMessage) // توسط کاربر به عنوان در SPD اعلام شده به تصویب رسید.

این اهرم این واقعیت است که ما می توانیم در اطلاعات گردش کار مهم, مثل سایت, لیست 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!

متاسفانه, این واضح است که یک بلیط یک طرفه به پایین "Loosey Goosey" ضد الگوی زمین, but it’s better than hitting a brick wall 🙂

آیا یک الگوی ضد اگر شما آن را انجام دهد حتی اگر شما می دانید آن را یک الگوی ضد?

I hope to wrap this inside Codeplex in the near future. If you’re interested in me doing so, چیزای من بهم زدن (پست الکترونیک یا ترک یک دیدگاه) and I’ll be that more enthusiastic about doing it 🙂

</پایان>

مشترک شدن در وبلاگ من.

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) "قلم دوم از اقلام مربوط به" in a new window. This provides one-click access to the meta data of the related item. This is what I mean:

خوشبختانه, we can do that and it’s not very hard. Broadly speaking, آتش تا 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, جستجو و یا سایر حالات XSL, this will be easy for you. در واقع, که من پیدا کردم آن را به طور کلی آسان تر از فرم تولید شده است تا حدودی ساده تر به دنبال در مقایسه با نتایج جستجو وب بخش اصلی (و یا 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 با دست.
• آزمون (کنترل کنید که تغییرات خود را به درستی ذخیره شد و چیزی را پاره کند).
• باز کردن گردش کار و اضافه کردن یک عمل نامربوط (از قبیل "ورود به سیستم به تاریخ").
• صرفه جویی در گردش کار.

نتیجه: در این مورد, SPD دوباره ایجاد فرم.

تست 2:

• همه گروه همان #1 جز به طور مستقیم "جمع آوری اطلاعات از یک کاربر را تغییر دهید" اقدام.

نتیجه: این دوباره ایجاد فرم از ابتدا, بیش از نوشتن همه تغییرات مورد نظرتان را در.

یادداشت های نهایی:

• حداقل دو عملیات SPD ایجاد اشکال مثل این: "جمع آوری اطلاعات از کاربر" 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 <یک عکاس هنگام عکسبرداری> 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 کندو که من می توانم تغییر را تحت تاثیر قرار SPD تولید اشکال پیش فرض (ما می توانیم قالب های هشدار را تغییر دهید).

</پایان>

مشترک شدن در وبلاگ من!

من یک سناریوی کسب و کار مثل این:

• ارسال کاربر یک سند به کتابخانه اسناد.
• او یک نوع محتوا را انتخاب و وارد داده های متا به عنوان مورد نیاز. یکی از زمینه های داده متا یک پرچم است, "Urgent".
• این باعث گردش کار شیرپوینت طراح است که, در میان چیزهای دیگر, uses the "Collect Data from a User" اقدام.

"Collect Data from a User" ایجاد یک آیتم در یک لیست کار درخواست تایید برای آن سند,,en,من نیاز به ایجاد یک دیدگاه از لیست کار که درخواست فوری برای تصویب نشان داد,,en,قرار دادن کلمه "فوری,,en,به عنوان این وظایف,,en,من ترجیح داده اند برای مشخص درست اولویت به طور مستقیم,,en,من قادر به انجام این کار به چند دلیل بود,,en,عمل جمع آوری داده ها هیچ مکانیزمی را فراهم نمی کند برای به روز رسانی هر رشته دیگر از عنوان,,en,و کسانی که زمینه های اضافی که شما می خواهید به جمع آوری داده,,en,به "اختصاص یک آیتم به انجام,,en,عمل همان مشکل,,en,این ممکن است برای وارد کردن یک آیتم را به یک لیست,,en,درج یک آیتم را به لیست کار به طور مستقیم,,en,اما این یک عمل مسدود کردن,,en,این بدان معناست که گردش کار نمی خواهد صبر کنید برای کاربر کامل است که وظیفه,,en,من چند روش قبل از در نظر گرفته,,en,خوشبختانه,,en.

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

راه حل: Put the word "URGENT:" into the title of these tasks.

I would have preferred to specify the priority field directly. اما, 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.

اما, 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, لطفا اجازه دهید من می دانم.

</پایان>

تکمیلی: Madjur Ahuja از این لینک از یک بحث گروه خبری: 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, آنها می توانند بر روی لینک ایمیل کلیک کنید و به طور مستقیم به فرم InfoPath.

این هیولا 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

به جای متن قرمز ضخیم با نام از فرم, همانطور که در تصویر زیر نشان داده شده است:

توجه داشته باشید که بسیاری از مسیر hard-coded بودن در این آدرس وجود دارد, 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" (i.e. هر کس). 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.

آیا من می توانم با پر کردن و ذخیره یک فرم به کتابخانه? –> بله

آیا می توانم این کار دسترسی پیدا کنم از لینک ایمیل? –> بله

گردش کار ویرایش لینک کار می بینم –> بله

آیا من می توانم بر روی این لینک کلیک کنید? –> NO … مجوز.

چرا لینک ویرایش را انکار می کند که به من اجازه می بینم وقتی که من بر روی آن کلیک کنید? 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

از پوستر به نظر می رسد نشان می دهد که عمل ساده صادرات گردش پلاتر هارد را یک مسئله امنیت خزه تعمیر? 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.

پس, چیزی برای از دست دادن, من آتش SPD, گردش کار راست کلیک کنید و آن را ذخیره کنید به ج:\ 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, شما باید از گزینه جعبه.

برای حل آن, create a custom action that provides a string replace function to use in your workflow. Alternatively, استفاده از یک ابزار از 3rd party از قبیل بسته بندی عالی در اینجا: http://www.codeplex.com/spdwfextensions 🙂

</پایان>

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.

<پایان پیام />

سناریوی: در طراح شیرپوینت گردش کار, 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 [DateField] 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"/>

برای اولین بار نشان می دهد مانند این در SPD:

در حالی که دومی را نشان می دهد مثل این:

من مطمئن هستم که چگونه مفید این عکس روی صفحه نمایش هستند نیستم اما من در تلاش به آنها را، بنابراین شما باید آنها را مشاهده قرار 🙂

مشاهده است: StringBuilder به شما اجازه می دهد برای ساخت رشته (بدیهی است که) با مخلوط کردن با هم رشته و گردش داده ها (via the "Add Lookup" را فشار دهید در پایین گوشه سمت چپ). When you use the Add Lookup button, it inserts a token in the form "[%token%]". When SharePoint invokes your custom action, (C# code in my case), SharePoint passes the token itself, not the value of the token. If you use the default designer type (the second type), SharePoint expands the token and passes actual value of the token to your action.

StringBuilder = BAD, default designer type = 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 (which incidentally is exactly what one does to create a dynamic subject for the email action, اما این موضوع برای ورود به وبلاگ دیگر, کندهار کندهار).

<پایان پیام />