I wrote up a detailed article a few weeks ago describing how to create a SharePoint Designer workflow that sends a task reminder email on a daily basis. It’s been објавено на нови SharePoint списание сајт. More generally, на статија покажува како да се создаде looping структура во СПД.

Списанието има широк спектар на артикли, вклучувајќи, меѓу другото, многу технички работи, interviews and industry news. I recommend you add it to your RSS feed.

Ако имате производ или услуга да се продаде, I’d also consider advertising on the site. It’s off to a strong start with several thousand pairs of eyes looking at it already. That’s sure to grow.

И на крај, ако сте биле чешање да напише нешто и да го во предниот дел на поголема публика, this is a great time and place to scratch it.

</крајот>

Да се ​​претплатите на мојот блог.

Марк Милер во текот на Крајниот корисник SharePoint has posted my latest article about using SharePoint Designer to create great workflow solutions up on his site. Проверете го ова.

Во овој напис, Зборувам за дизајн процесот и, во поголеми детали, како да се постави сигурен и повторливи тест процес користејќи SharePoint карактеристики (сопствени листи, сајт шаблони). The article targets End Users, но пристапот е добро за програмери премногу.

</крајот>

Да се ​​претплатите на мојот блог.

Минатата недела, Бев работат надвор како да се јамка и спроведувањето на државната машина користејќи SharePoint дизајнер и спомна, Како настрана, дека јас веројатно ќе напише блог пост за подобра Workflow сеча.

И, Sanjeev Rajput beat me to it. Имаат поглед.

Заштеда на дневниците со податоци во обичај листата се чини супериорен во однос на користење на редовните работното историја:

• Тоа е само обичај листа, па ќе може да извезува на тоа во Excel многу лесно.
• Можете да креирате пати, динамички филтер на податоци, итн.
• Тоа не е предмет на авто-чистка добивате со редовен работен проток историја.

Постојат одредени ризици / downsides:

• Многу работи workflows со многу сеча би можело да предизвика премногу податоци за да бидат напишани на списокот.
• Maybe you *do* want automatic purging. You don’t get that feature with this approach (без кодирање).
• Security is tricky. In order to write to the list, the user must have permission to do so. That means that it’s probably not suitable for any kind of "official" audit since the user could discover the list and edit it. This could be overcome with some custom programming.

</крајот>

Да се ​​претплатите на мојот блог.

This past week I finished off a proof of concept project for a client in Manhattan. While implementing the solution, Истрчав во друг недостаток на Мос KPIs (види тука за претходната KPI прашање и мојот заобиколи).

Позадина: We used SharePoint Designer workflow to model a fairly complex multi-month long business process. As it chugged along, it would update some state information in a list. KPIs use this data to do their mojo.

We decided to create a new site each time a new one of these business processes kicks off. Aside from the workflow itself, овие сајтови домаќин неколку документ библиотеки, use audience targeting and so forth. Just a bunch of stuff to help with collaboration among the internal employees, патуваат вработени и кои учествуваат на клиентот деловни партнери.

Ние исто така, сакаше да покаже некои KPIs што вршат мониторинг на целокупното здравје на таа специфична бизнис процес како промовирани од страна на тек на работа лидери на податоци и видени со користење на KPIs.

Конечно, ние се користи KPI предметите од листата кои го прават тоа една брои на еден поглед основа на листа во сајт (како што се противат за погодок во од друг извор на податоци, како ексел или SQL).

На Проблем: Како што можете може да се замисли, претпоставувајќи бевме за да се го носат на основната идеја напред во производство светот, we would want a site template. Provision a new site based off a "business process" дефиниција.

The problem is that you can’t seem to get a functioning KPI that way. When I create a new site based on a template with a KPI List and KPI web part, the new site’s KPI data are broken. The new site’s KPI list points at whatever source you defined when you first saved it as a template.

По пат на пример:

• Create a new site and build it to perfection. This site includes the KPI data.
• Зачувајте ја таа како дефиниција.
• Се создаде нов сајт и да база ако исклучени на дефиниција.
• Оваа нова веб страна е KPI предметите од листата’ извори укаже на сајт дефиниција, не на тековната сајт.

На примерна процес не се се поправи на URL-то.

I tried to solve this by specifying a relative URL when defining the KPI list item. Сепак, Јас не би можеле да добијат било која варијација на дека за да се работат.

I always want to pair up these "problem" блог постови со некои вид на решение, but in this case I don’t have a good one. The best I can figure is that you need to go in to the newly provisioned site and fix everything manually. The UI makes this even harder because changing the URL of the source list causes a refresh, така што навистина треба да се редефинира на целата работа од нула.

Ако некој знае подобар начин да се се справи со ова, Ве молиме да поставите коментар.

</крајот>

I’ve recently learned that it’s possible and even fairly easy to create a state machine workflow using SharePoint Designer. Necessity is the mother of invention and all that good stuff and I had a need this week that looked for an invention. Coincidentally, Наидов овој MSDN форум како и. My personal experience this week and that "independent confirmation" lends strength to my conviction. I plan to write about this at greater length with a full blown example, но тука е главното обележје на тоа:

• Пристапот Нотингем фактот дека работното може да го промени елемент во листата, thereby triggering a new workflow. I’ve normally considered this to be a nuisance and even блогираа за користење semaphores да се справи со неа.
• SharePoint овозможува на повеќе независни workflows да бидат активни против одредена ставка од списокот.

Да го конфигурирате:

• Дизајнирате вашата државна машина (односно, на држави и како државите во транзиција од една до друга).
• Спроведување на секоја држава како посебни работното.
• Конфигурирате секој од овие државни workflows да се изврши како одговор на каква било промена на елемент во листата.

Секоја држава работното ја следи оваа груба шема:

• По иницијализација, determine whether it should really run by inspecting state information in the "current item". Abort if not.
• Завршат работата.
• Update the "current item" with new state information. This triggers an update to the current item and fires off all the state workflows.

Настрана од очигледна корист што може да се создаде само декларативно државна машина работното, сите што државата информации е страшно за градење KPIs и интересни пати.

Тоа не имаат прилично значителен недостаток — standard workflow history tracking is even more useless than normal 🙂 That’s easily remedied, сепак. Store all of your audit type information in a custom list. That’s probably a good idea even for vanilla sequential workflow, but that’s for another blog post 🙂

I call this a "mea culpa" бидејќи имам, за жал,, said more than once on forums and elsewhere that one must use visual studio to create a state machine workflow. That simply isn’t true.

</крајот>

Да се ​​претплатите на мојот блог.

It’s possible to cause an endless loop in a SharePoint Designer workflow. A common implementation pattern like this causes the problem:

• Создаде работа и се дружат со листа.
• Укажуваат на тоа дека треба да почне на создавање на нови предмети и надградба на постоечките ставки.
• A step in the workflow updates a field in "Current Item".
• Со оглед на тековната содржина промени, на работното започнува одново.

За да се спречи оваа бескрајна јамка, имплементира едноставен семафор:

• Додај сајт колона (или колона на листата / библиотека ако не сте со користење типови содржини).
• Скрие од страницата уреди (лесно да се направи ако еден сајт колона преку своите имоти, не е толку лесно ако список колона).
• Во работното, провери да се види дали вредноста на семафор колона не е празно.
• Ако тоа не е празно, поставите тоа да не-празни вредности и да продолжи.
• Ако не е празно, излезете веднаш.

Ова може да стане прилично суптилна решение, во зависност од барањата на бизнис и така натаму, но тоа е употреблива шема кога сум се потребни.

</крајот>

Да се ​​претплатите на мојот блог.

Како што многу луѓе знаат, на вработените Обука дефиниција обезбедени од страна на Microsoft тука има грешка дека ние може да репродуцира следниве чекори:

• Се создаде една класа со големина максимум од 10 студенти.
• Регистрирај се –> Total available seats properly decrements by one. Резултира: 9 расположивите места.
• Одрегистрираш: –> Bug. Total available seats should increment by one. It does not. Резултира: 9 расположивите места, како на SharePoint, но всушност, постојат 10 расположивите места.

Решение: Го користите SharePoint Designer да се поправи на работното.

Прва, open up the site. The folder list for me looks like this:

If we have a look at the "Attendee registration" работното, we see that there is a step labeled "Enforce seating policy". It looks like this:

This step in the workflow updates the item by incrementing the "Filled Seats" metadata column on the course. If we pull that up in more detail, гледаме овој:

Тоа е сите информации што треба да се поправи на работното регистрацијата.

Ако ние флип во текот на работното регистрацијата, there is no similar workflow step. Add it as follows:

1: Expand "Attendee unregistration" и се отвори XOML (се види од прва екранот ако сте изгубени).

2: Додај нов работното променлива, "New Filled Seats" of type "Number".

3: Assign a value to "New Filled Seats" како што е прикажано:

4: Намалување на Исполнет Седишта од 1:

5: Ажурирање на поврзани разбира содржина:

6: Make sure all the steps are in the right sequence. За мене, тоа би изгледало вака:

7: Заврши на работното повторно да се изгради тоа.

8: Тест.

</крајот>

Да се ​​претплатите на мојот блог.

Една од новите модели Сметам дека во изработката на SharePoint решенија Нотингем SharePoint Designer работното и настан приемник.

Тука е бизнис сценарио да го стави во контекст:

• Јас испратите документот на doc lib.
• Јас започне мулти-чекор работното создадени користејќи SharePoint дизајнер.
• Во одреден момент во текот на тој процес, работното доделува задача да некој (преку собирање на податоци од корисникот или доделите задача).
• We want to use a KPI to track how long that task is awaiting completion. The KPI shows green for tasks that are completed or due more than 3 days from now. It shows yellow if the task is due tomorrow or today. It shows red if the task is past due.
• Тука е критикар: Сакам датумот кој вози дека KPI да биде празник-свесни.

I can’t calculate a holiday-aware due date in SharePoint Designer workflow very easily. I would have to create a custom action or use a 3rd party tool. Сепак, it’s easy enough to calculate such a date in an event receiver. Merge those two together and we get a pattern like this:

• Define a hidden yes/no site column on the document library labeled "DoCalcualteDueDate".
• Иницијализира до лажна.
• Во соодветно време на работниот тек (e.g. just before the "collect data" акција), доделите таа вредност да Точно.
• На ItemUpdate() event receiver looks to see if "DoCalculateDueDate" is true. Since the event receiver runs on every update, "DoCalculateDueDate" е нормално лажни.
• Кога работното доделува DoCalculateDueDate на true, случај приемник ја пресметува празник-свесни датумот на доспевање.
• Кога настанот приемник прави оваа пресметка, го поставува DoCalculateDueDate знаме да се лажни.

На крајот, SPD workflow is communicated with an event receiver via the DoCalculateDueDate semaphore and we have holiday-aware due dates that are assigned at the exactly correct moment in the workflow’s life. SharePoint Designer controls when the due date is assigned but the event receiver performs the actual calculation and assignment.

</крајот>

Да се ​​претплатите на мојот блог.

Ажурирање: I’ve been researching how to embed a SPD workflow into a site definition. Овој форум MSDN синџир има некои интересни информации. It’s not conclusive, но укажува на пат низ џунглата.

I’m giving this post a slightly oddball "Observed Behavior" lead since I’m a little leery of drawing conclusions from it. SPD workflows are … темпераментен.

Луѓето често се прашуваат / се прашувам / fretting over moving SPD workflows from one place to another. Денес, Го следев овие чекори и направени овие забелешки:

• Јас создаде работното користејќи SharePoint дизајнер во еден сајт во прилог на документот библиотека.
• Придружните документ библиотека веќе биле сместени неколку документи.
• Чував сајт како дефиниција.
• Кога чував сајт како дефиниција, Чував содржина, како и.
• Јас создаде нов сајт во истата сајт за собирање помош која дефиниција.

Во овој момент, I tried to run the workflow. It promptly terminated itself with the log message, "Failed on start".

I expected this. I have low expectations when it comes to moving SPD workflows around.

Продолжив:

• Отвори сајт во SharePoint Designer.
• Had a peek at the workflow. It seemed fine.
• I clicked "Finish".
• Истрчав на работното.

Овој пат, тоа добро работеа.

I’ll add that this workflow used the "collect data from user" акција, која е релативно сложени акција под хауба.

I tentatively conclude that the process of "finishing" the workflow caused SPD to properly associate the SPD workflow with the new document library. I also conclude the XOML and other XML artifacts are reasonably "loose". They are not super tightly coupled to the document library.

Што значи ова? Assuming it’s a reliable and reproducible process, there’s at least one rough method we can use to move them around. I don’t know if this would work if we crossed site collection boundaries or even more drastically, Целиот нови фарми (e.g. dev да фаза да prod).

Ако ја читаш оваа и склон, Ве молиме да објавувате коментар или е-мејл мене your SharePoint Designer migration story. I’ll gladly update this posting with any insights thus offered.

</крајот>

Да се ​​претплатите на мојот блог.

It’s often useful to store status information in a custom list such as an approval code which should never be directly manipulated by end users. This is a common business scenario. I have been working on a project this year that generates various status and reminder dates via SharePoint Designer workflows that then drive KPIs and generally support time-critical business processes.

Use a site content type / column to achieve this effect.

Create a site content type with the status column as shown:

Note the "Status (for Demo)" field at the bottom.

Следна, click on the column name to access the column’s properties. Select "Hidden (Will not appear in forms)" in the Column Settings section as shown:

This removes the field from the standard edit/update forms. Сепак, се уште е на располагање во пати, KPIs, објектот модел и никаде на друго место дека сакате да ја користите, including SPD workflow.

</крајот>

Да се ​​претплатите на мојот блог.