Съм написал подробна статия преди няколко седмици, който описва как да създадете работен поток на SharePoint Designer, който изпраща имейл задача напомняне на дневна база. Той е бил публикувани в новия SharePoint списание сайт. По-общо, статия показва как да създадете циклична структура в контекста на ЕПД.

Списанието има голямо разнообразие от членове, включително, наред с други неща, много технически неща, интервюта и новини промишленост. Аз препоръчвам да го добавите към вашия RSS емисия.

Ако имате един продукт или услуга да продават, Също смятам реклама на сайта. Тя е на разстояние до силен Старт с няколко хиляди чифта очи, гледащи го вече. Това е сигурен да растат.

На последно място, Ако сме били сърбеж да напиша нещо и да го измъкнем пред по-голяма аудитория, Това е много време и място да го нулата.

</край>

Абонирайте се за моя блог.

Марк Милър над в Краен потребител SharePoint осчетоводена последния ми статия за използването на SharePoint Designer, за да създаде голям поток решения нагоре на своя сайт. Проверете го.

В тази статия, Аз говоря за процеса на проектиране и, по-подробно, Как да зададете надеждни и повторяеми тест процес с помощта на функции на SharePoint (потребителски списъци, шаблони за сайтове). Статията е насочена към крайните потребители, но подходът е прекалено добър за разработчици.

</край>

Абонирайте се за моя блог.

Миналата седмица, Бях на работа, как да циклично изпълнение и прилагане на машина на състоянията с помощта на SharePoint Designer и посочени, като настрана, че аз вероятно ще пиша в блог пост за по-добър поток сеч.

Ами, Sanjeev Rajput ме биеш с него. Вижте.

Записване на данните от регистрационните файлове в списък по избор изглежда превъзходно да използват хронологията на редовен поток:

• Това е само един потребителски списък, така че можете да експортирате да превъзхожда много лесно.
• Можете да създадете изгледи, динамично филтриране на данни, н.
• Това не е предмет на авто-чистка получавате с редовен поток история.

Има някои рискове / недостатъци:

• Много изпълняващи се работни потоци с много влизане може да доведе до твърде много данни, за да бъдат записани в списъка.
• Може би сте * ли * искате автоматично прочистване. Вие не получите тази функция с този подход (без кодиране).
• Сигурност е сложен. За да пишат в списъка, Потребителят трябва да има разрешение да го направите. Това означава, че вероятно не е подходящ за всякакъв вид на "Официален" одит, тъй като потребителят може да откриете списъка и да го редактират. Това може да бъде преодоляна с някои програмиране.

</край>

Абонирайте се за моя блог.

Това миналата седмица аз довърших доказателство за идеен проект за клиент в Манхатън. При изпълнение на решението, Аз се блъсна в друг недостатък на Мос KPI (Вижте тук за един предишен въпрос KPI и моите workaround).

Фон: Ние използват SharePoint Designer поток за модел доста сложни мулти-месец дълго бизнес процес. Като го chugged, то ще update някои състояние информация в списък. KPI използват данните, за да направят своите mojo.

Ние решихме да се създаде нов сайт всеки път, когато започва на нов един от тези бизнес процеси. Настрана от самия работен поток, тези сайтове домакин няколко библиотеки с документи, използват за насочване към аудитория и т.н.. Само един куп неща, които да помогнат с тясното сътрудничество между вътрешни служители, пътуващи служители и клиенти на участващите бизнес партньори.

Ние също исках да покаже някои KPI, който следи за цялостното здраве на този определен бизнес процес, като насърчавани от данните за състоянието на работния поток и преглеждат с помощта на KPI.

Най-накрая, Ние използвахме KPI списък елементите, които се броят на изглед на списък в сайта на (вместо да дърпа от друг източник на данни, като excel или SQL).

Проблемът: Както можете да си представите, Ако бяхме да носят основната идея напред в света производство, ще искаме шаблон на сайт. Осигуряване на нов сайт базирани извън "бизнес процес" шаблон.

Проблемът е, че не може да изглежда да получите функционираща KPI по този начин. Когато създам нов сайт, базиран на шаблон с KPI списък и KPI уеб компонент, Новият сайт на KPI данни са повредени. Новият сайт на KPI списък точки в независимо източника дефинирано когато първо е записан като шаблон.

Като пример:

• Създаване на нов сайт и го построили до съвършенство. Този сайт включва данни от KPI.
• Това записване като шаблон.
• Създаване на нов сайт и база ако извън шаблона.
• Този нов сайт елементите KPI списък’ източници сочат към шаблона на сайта, не текущия сайт.

Процесът на примерна does не правилен URL.

Опитах се да реши това като посочите относителен URL адрес, при определянето на KPI списъка елемент. Въпреки това, Не може да получи всяко отклонение от това да работи.

Аз винаги искам да свърже тези "проблем" блог постове с някакъв вид на разтвор, но в този случай не са един добър. Най-добрите аз мога фигура е, че трябва да ида на новострояща провизирани сайта и да определи всичко ръчно. Интерфейса прави още по-трудно, тъй като промяна на URL на списъка източник причинява обновяване, така че наистина трябва да се предефинира всичко от нулата.

Ако някой знае по-добър начин за справяне с това, Моля публикувате коментар.

</край>

Наскоро научих, че това е възможно и дори сравнително лесно да се създаде машина състояния, с помощта на SharePoint Designer. Необходимостта е майка на изобретението и всички добри неща и имах нужда тази седмица, че погледна за изобретение. По стечение на обстоятелствата, Дойдох в този MSDN форум пост както и. Моят личен опит тази седмица и че "независима потвърждение" придава здравина на моето убеждение. Смятам да пиша за това в по-голяма дължина с пълна разпенени пример, но тук е същността на това:

• Подход подсилва факта, че работен поток може да промените елемент от списък, по този начин се задействат нов работен поток. Аз обикновено счита това да бъде неудобство и дори Blogged за използването на семафори да се справя.
• SharePoint позволява множество независими работни потоци да бъдат активни срещу конкретен елемент.

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

• Проектиране вашата държавна машина (т.е., членки и как членки преход от един към следващата).
• Прилагане на всяка държава като отделен работен поток.
• Конфигуриране на всеки от тези потоци на държавата да изпълни в отговор на промяна в елемент от списъка.

Всяка състояния следва този груб модел:

• При инициализация, определи дали наистина трябва да изпълни от проверяващите държава информация в "текущия елемент". Прекъсване ако не.
• Вършат работа.
• Актуализация "текущия елемент" с нова държава информация. Това предизвиква актуализация на текущия елемент и пожари на разстояние всички държавни работни потоци.

Освен очевидната полза че човек може да създаде машина с декларативен състояния, всичко, което състояние информация е страхотно за изграждане на KPI и интересни мнения.

Тя има един доста съществен недостатък — standard workflow history tracking is even more useless than normal 🙂 That’s easily remedied, Въпреки това. Всичките си одит тип информация се съхранява в списък по избор. Това вероятно е добра идея дори за ванилия последователен работен поток, but that’s for another blog post 🙂

Аз наричам това "mea culpa" защото имам, за съжаление, каза повече от веднъж на форуми и другаде, че трябва да използва visual studio за създаване на държава машина работен поток. Това просто не е вярно.

</край>

Абонирайте се за моя блог.

Възможно е да предизвика зацикляне в SharePoint Designer поток. Общ прилагане модел като това причинява проблема:

• Създаване на работен поток и асоциирани със списък.
• Показват, че тя трябва да започне на създаване на нови елементи и актуализиране на съществуващи елементи.
• Стъпка в работния поток актуализира поле в "Текущия елемент".
• Тъй като текущия елемент се промени, Работният поток започва отново.

За да се предотврати този безкраен цикъл, изпълнение на прости семафор:

• Добавяне на колона на сайт (или колона в списък/библиотеката, ако не използвате типовете съдържание).
• Го скрие от страницата за редактиране (лесно да се направи ако на колона на сайт чрез неговите свойства, не е толкова лесно, ако колона на списък).
• В работния поток, Проверете дали стойността на колоната semaphore е празно.
• Ако е празно, поставям то към непразна стойност и продължете.
• Ако е не е празно, Излезте веднага.

Това може да стане доста нюансиран решение, в зависимост от бизнес изисквания и т.н., но това е било един работещ модел, когато аз съм нужда то.

</край>

Абонирайте се за моя блог.

Както много хора знаят, шаблон за обучение на персонала предоставени от Microsoft тук има една грешка, която ние може да възпроизвежда следните стъпки:

• Създаване на клас с максимален размер на 10 студенти.
• Регистрирайте се –> Общо наличните места правилно понижаване от един. Резултат: 9 свободните места.
• Дерегистриране на: –> Бъг. Общо наличните места трябва да нарастване от един. Тя не. Резултат: 9 свободните места както на SharePoint, но в действителност, има 10 свободните места.

Разтвор: Използвайте SharePoint Designer, за да коригирате работния поток.

Първо, отвори сайта. Списък на папките за мен изглежда така:

Ако имаме един поглед на "участник регистрация" работен поток, виждаме, че има една стъпка, с надпис "Прилагане за сядане политика". Тя изглежда така:

Тази стъпка в работния поток актуализира елемента като Инкрементиращи "пълни места" метаданни колона на курса. Ако ние, издърпайте нагоре по-подробно, Ние виждаме това:

Това е цялата информация, трябва да се определи отписването поток.

Ако ние се обърнете към отписване поток, няма никаква подобна стъпка от работния поток. Го добавите както следва:

1: Разгънете "участник отписване" и ще отвори XOML (Вижте първият преглед ако сте загубен).

2: Добавяне на нова променлива на работния поток, "Нови напълнена места" от тип "Номер".

3: Присвоите стойност на "нови запълнени места" както е показано:

4: Снижаване напълнена места от 1:

5: Актуализира съответния артикул курс:

6: Уверете се, всички стъпки са в правилната последователност. За мен, Тя изглежда така:

7: Завърши работният поток да изградят отново.

8: Тест.

</край>

Абонирайте се за моя блог.

Един от новите модели, намирам в изработването на решения на SharePoint лостове SharePoint Designer поток и получател на събитие.

Ето един бизнес сценарий да я тури в контекст:

• Аз upload документ към библиотека с документи.
• Аз започне мулти-стъпка работен поток, създадени с помощта на SharePoint Designer.
• В един момент по време на този процес, Работният поток възлага задача на някой (чрез събиране на данни от потребителя или възлагане на задача).
• Ние искаме да използвате KPI, за да следите колко дълго тази задача е в очакване на завършване. KPI показва зелено за задачи, които са завършени или падеж повече от 3 дни от сега. Тя показва жълт, ако задачата се дължи утре или днес. Тя показва червен, ако задачата е просрочена.
• Тук е заядливец: Искам датата, която управлява този KPI да бъде празник aware.

Не може да изчисли празник aware падеж дата в SharePoint Designer поток много лесно. Аз ще трябва да създадете потребителско действие или използването на трета страна инструмент. Въпреки това, лесно е достатъчно, за да изчислите тази дата в получател на събитие. Слеят тези две и получаваме модел като този:

• Дефинира един скрит да/не колона на сайта на библиотеката с документи с надпис "DoCalcualteDueDate".
• Инициализиране на фалшиви.
• В подходящ момент в работния поток (e.g. точно преди "събира данни" действие), присвоите тази стойност True.
• ItemUpdate() събитие получател изглежда да видите дали "DoCalculateDueDate" е вярно. Тъй като събитието приемника работи на всяка актуализация, "DoCalculateDueDate" е обикновено фалшиви.
• Когато работният поток възлага DoCalculateDueDate на true, на събитието приемник изчислява празник aware дължимата дата.
• Когато събитието приемника не това изчисление, Тя установява флаг DoCalculateDueDate на фалшиви.

В края, ЕДП поток се предава с получател на събитие чрез DoCalculateDueDate семафор и имаме празник aware поради дати, които са присвоени на точно подходящия момент в живота на работния поток. SharePoint Designer контроли, когато датата на падеж е присвоена но събитието приемника извършва реалното изчисление и присвояване.

</край>

Абонирайте се за моя блог.

АКТУАЛИЗИРАНЕ: Аз бях изследва как да вградите на ЕПД работен поток в дефиниция на сайт. Тази верига MSDN форум има интересна информация. Не е решаващо, но точки път през джунглата.

Аз съм като този пост малко Одбол "наблюдава поведение" олово, тъй като аз съм малко подозрителен изводи от нея. ЕДП работни потоци, които са … темпераментен.

Хората често се питат / чудите / люта над преместване ЕДП работни потоци от едно място на друго. Днес, Аз последовател тези стъпвам и направи тези наблюдения:

• Аз създадох работен поток, като използват SharePoint Designer в даден сайт, към библиотека с документи.
• Библиотеката на свързания документ вече настанени няколко документа.
• Аз записали на сайта като шаблон.
• Когато записали на сайта като шаблон, Аз спасих съдържание, както и.
• Съм създал нов сайт в същата колекция от сайтове с помощта на този шаблон.

В този момент, Опитах се да стартирате работния поток. Той незабавно прекратява себе си с регистрационното съобщение, "Неуспех при стартиране".

Очаквах това. Имам ниски очаквания, когато става въпрос за придвижване ЕДП работни потоци.

Аз продължих:

• Отвори сайт в SharePoint Designer.
• Имаше един поглед в работния поток. Той изглеждаше добре.
• Аз щракване "Свършвам се".
• Тичах работния поток.

Този път, мина успешно.

Аз ще добавя, че този работен поток използва "събира данни от потребителя" действие, което е относително комплексно действие под капака.

Аз колебливо заключи, че в процеса на "довършителни" работния поток, причинени SPD да правилно се свържете ЕДП поток с новата библиотека с документи. Аз също така да сключи XOML и други XML артефакти са разумно "насипно състояние". Те не са супер плътно свързани към библиотеката с документи.

Какво прави това означава? Ако приемем, това е надежден и възпроизводими процес, има поне един груб метод, можем да използваме да ги движите. Не знам дали това ще работи, ако пресякохме колекция границите на обекта или дори по-драстично, цялата нови ферми (e.g. Dev сцената на про).

Ако четеш това и наклонени, Моля публикувате коментар или пишете ми вашата SharePoint Designer миграция история. Аз с удоволствие ще актуализира този постинг с някакви прозрения по този начин предлагат.

</край>

Абонирайте се за моя блог.

Тя често е полезно да се съхранява информация за състоянието в списък по избор като код на одобрение, който никога не трябва да бъде директно манипулирани от крайните потребители. Това е един общ бизнес сценарий. Съм бил на работа по проект тази година, който генерира различни дати за статус и напомняне чрез SharePoint Designer работни потоци, които след това карам KPI и обикновено поддържат време критичните бизнес процеси.

Използвайте тип съдържание на сайт / колона за да се постигне този ефект.

Създаване на тип съдържание на сайт с колоната състояние, както е показано:

Обърнете внимание на "състоянието (за демо)" в полето в дъното.

Следващ, щракнете върху името на колоната за достъп до свойствата на колоната. Изберете "скрити (Няма да се появи във форми)" в раздела Настройки на колони както е показано:

Това премахва полето от стандартните Редактиране/актуализиране на формулярите. Въпреки това, Тя е все още налична в изгледите, KPI, Обектният модел на и навсякъде другаде, които искате да го използвате, включително ЕДП поток.

</край>

Абонирайте се за моя блог.