Този блог пост е повече от "в сферата на възможното" срещу запис. конкретни информация.

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

Аз съм голям фен на декларативно поток, както и слаб visual studio поток програмист, така че аз исках да отговарят на изискванията, с помощта на SharePoint Designer.

Смятам да пиша за това по-подробно (и Надявам се представя една потребителска група или две през следващата година), но тук е цялостно решение:

• Създаване на потребителско действие, което интегрира със SPD.
• Действие по избор позволява SPD да се позове на уеб услуга и го предаде низ от XML.
• Уеб услугата открива ред в списък по избор и се създава нов сайт според данните за този нов клиент, използване на дефиниция на сайт по избор.
• Уеб услуга след това актуализира списък с информация като връзка към новия сайт.

Ние разглежда други подходи, манипулатори и visual studio базирани поток. ЕДП подход дава нашите крайни потребители малко по-голям контрол над процеса на. Отпуска, има много на C# код в този разтвор, но това е поставено вътре декларативно поток, така че ние се някои от ползите от декларативно поток докато кука в услугата за създаване на сайт.

Всичко, от което се нуждаем сега, е лесен инструмент за автоматично мигриране на работните потоци на SPD възможно най -лесно за визуални студийни работни процеси и наистина ще готвим с газ 🙂 Разбирам, че някои хора работят по този проблем и се надявам, че имат скоро ще има добър успех.

</край>

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

Аз бях играя наоколо с потребителски действия за SharePoint Designer за известно време (Вижте тук за някои подробни неща, Ако това ви интересува).

В сегашния си проект, Ние трябва да направим някои доста тежки повдигане и ние искаме да използвате декларативно ЕДП поток за управление на свързаните с тях бизнес процеса.

Дълга история кратко, Това е напълно възможно. Аз разширена ми Codeplex проект да се позове на "помощник услуга" и сега ние може да се позове на уеб услуга директно от работен поток на ЕПД.

Тук е подпис:

 обществени низ Експедитор(
        GUID WebID, // Приет от runtime environment
        GUID SiteID, // Приет от runtime environment
        низ ListID, // Приет от RTE (не знам защо това е низ, не е GUID)
        INT ListItemID, // Приет от RTE.
        низ XmlMessage) // Преминали от страна на потребителя, както са декларирани в ЕПД.

Това подсилва факта, че можем да вземем най-важна поток информация, Подобно на сайта, ИД на списък, н. Това е добре документирано в няколко места, за тези от вас се интересуват от създаването на собствен потребителски действия. Идеята е да извлечете XML низ, както е предвидено от страна на потребителя да изпраща подходяща процедура. Забавни неща!

За съжаление, Това очевидно е еднопосочен билет до "Loosey Goosey" Анти-модел земя, but it’s better than hitting a brick wall 🙂

Е това анти-модел, ако го направя, въпреки че знаете, че това е анти-модел?

Надявам се да наслагвате това вътре Codeplex в близко бъдеще. Ако сте заинтересувани от мен по този начин, Дайте ми мушкам (имейл или оставете коментар) and I’ll be that more enthusiastic about doing it 🙂

</край>

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

Аз съм работи по проект, който използва пет различни SharePoint Designer работни потоци, за да се справят с някои одобрения на документи. ЕПД предвижда "събира данни от потребител" действие така че можем да Питай потребителя за различни битове на информация, като например дали те го одобри, някои коментари и може би питам какво са за вечеря онази вечер.

Формулярите са напълно функционални. Те са обвързани със списък със задачи като тип на съдържание. Те са 100% генериран от системата. Това е тяхната сила и слабост. Ако можем да живеем с формуляр по подразбиране, тогава ние сте добре да тръгвам. Въпреки това, Ние нямаме твърде много контрол върху как ЕДП създава формуляр. Ако ние не харесва това поведение по подразбиране, Ние трябва да прибягват до различни трикове, за да получите около него (за пример, Задаване на приоритет на задача).

Трябваше да осигури връзка на тези задача форми, които отвориха свойства на изгледа (dispform.asxp) на "свързани елемента" в нов прозорец. Това осигурява достъп с едно щракване на мета данни от съответния артикул. Това е, което искам да кажа:

За щастие, можем да направим това и не е много трудно. Най-общо казано, Запалете SPD, Навигирайте до директорията, която къщи файловете на работния поток и отворете ASPX файла, който искате да промените. Това са само класически XSL трансформация инструкции и ако вие сте изхвърлените с itemstyle.xsl, търсене или други XSL сценарии, Това ще бъде лесно за вас. Всъщност, Намерих го да бъде по-лесно, тъй като създаденият формуляр е малко по-лесно да се следват в сравнение с търсене основните резултати уеб част (или кошмарен CWQP).

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

Тест 1:

• Промяна на ASPX файла на ръка.
• Тествайте го (Проверете дали вашите промени са записани правилно и не прекъсва нещо).
• Отворете работния поток и добавяне на несвързани действие (например "Влезте в историята").
• Запиши работния поток.

Резултат: В този случай, ЕДП не създаде отново формуляра.

Тест 2:

• Правят същото като #1 Освен директно промяна "събира данни от потребител" действие.

Резултат: Това създава отново формата от нулата, -записване на вашите промени.

Заключителни бележки:

• Най-малко два ЕДП действия създават форми като този: "Събиране на данни от потребител" и "Присвоите елемент". И двете от тези действия’ Формулярите могат да бъдат променени ръчно.
• Аз бях в състояние да генерира ми линк към dispform.aspx, защото, в този случай, елемент се отнасят винаги има неговият ИД, вграден в свързаните артикули URL. Аз бях в състояние да го разархивирайте и след това изгради <a href> въз основа на него да предостави достъп до функцията на един щракване мета данни. Това е малко вероятно, че вашата URL следва това правило. Може да има други начини да получите ИД на съответния артикул, но аз не съм имал да пресече моста, така че аз не знам дали получава от другата страна на пропастта.
• Аз не разследва, но аз не бих се изненадал, ако има някакъв вид на файл за шаблон във 12 кошер, че мога да променят да повлияе как ЕДП генерира формулярите по подразбиране (много като ние можем да променят шаблони за известяване).

</край>

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

Имам бизнес сценарий като този:

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

"Събиране на данни от потребител" създава елемент в списък със задачи, иска одобрение за този документ.

Аз нужда за създаване на изглед на списъка със задачи, който показа спешни искания за одобрение.

Разтвор: Постави думата "спешно:" в заглавието на тези задачи.

Бих предпочел да зададете полето приоритет директно. Въпреки това, Аз бях в състояние да направи това по няколко причини:

1. Действието събиране данни не предоставя механизъм за актуализиране на всяко поле освен заглавие (и тези допълнителни полета, за които искате да съберете данни).
2. "Разпределение на елемент" действие има същия проблем.
3. Възможно е да вмъкнете елемент в списък (т.е.. Вмъкване на елемент в списъка със задачи директно) но това не е блокиращо действие. Това означава, че работния поток няма да чака за потребителя да завърши тази задача.

Счетох няколко подходи преди (за щастие) Осъзнавайки ние може просто сложи "спешно" в заглавието.

1. Стартиране на работен поток в списъка със задачи, себе си, така че когато се създава нова задача, Тя по някакъв начин пресичат препратки обратно към документа, който започна първият работен поток, извади стойността на спешно флаг и актуализира приоритет както нужда.
2. Нещо подобно с получател на събитие. При създаване на задача, Намерете на свързания документ и актуализация на приоритет, ако е необходимо.
3. Използвайте "създаване на елемент от списък" действия във връзка с "Изчакайте промяна на поле" действие и получател на събитие. Ако ние се създаде елемент от списък, Ние може да зададете всички полета, искаме. Използвайте получател на събитие, за да актуализира първоначалния елемент, когато потребителят завърши задачата и "Изчакайте промяна на поле" състоянието на действие ще бъде изпълнено и работния поток ще продължи. (По някаква причина, Аз повече или по-малко се заселили на този подход преди разумно да реши да си тръгне за известно време).

Има един недостатък на моето решение (Освен очевидния факт, че само текста на заглавието показва спешност). Тъй като "събиране на обратна информация" приема само твърди кодирани заглавие имена, Трябва да използвате две различни събиране на обратна връзка действия, чиято единствената разлика е, че трудно кодирани заглавие.

Но, най-малко има едно решение, което не изисква събитие получател или обичай ЕДП действия.

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

</край>

АКТУАЛИЗИРАНЕ: Madjur Ahuja посочва тази връзка от дискусионна група дискусия: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Това е доста окончателно.

===

Ние често искат да вградите хипервръзки към формулярите на InfoPath в имейли, изпратени от SharePoint Designer работни потоци. Когато потребителите получавате тези имейли, те могат да кликнете върху линка от имейла и да отидете направо на формуляр на 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&Източник = http % 3а % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

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

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

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

</край>

Аз бях изпълнила работен поток, като използват SharePoint Designer в сайт, който е основно само за четене "NT_AUTHORITYAuthenticated потребители" (т.е.. всеки). Има библиотека с формуляри за формуляр на InfoPath. Има съответния поток списък задачи както и, така че когато поток работи, Тя може да възлагате задачи на хора.

Строша разрешение за формуляри библиотека и задача списък, така че всеки удостоверен потребител, за да създавате формуляри и актуализиране на възложените задачи.

Аз проверка с моите нисък-привилегии тестов акаунт.

Може да съм попълване и записване на формуляр в библиотеката? –> Да

Аз достъп до задачата от имейл връзка? –> Да

Мога да видя връзката редактиране за задача на работен поток –> Да

Може да щракнете върху тази връзка? –> Не … Разрешението е отказано.

Защо да видите връзката редактиране, която ме отрича разрешение, когато щракнете върху него? Това е не как е трябвало да работи…

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

Най-накрая, Търся Internets. Аз намирам този вероятна MSDN форум конец: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Плакати изглежда да се предполага, че Самият акт на износа на работния поток за диск Пома ще определи Мос сигурността? Трудно мога да повярвам, просто вид, че. Аз съм напомня на Южен парк епизод за 9/11 конспирация, където Стан е иска ни Preznit, "Наистина?" отново и отново.

Така, нищо за губене, Огън SPD, Щракнете с десния бутон върху работния поток и спасявам то към my буквата c:\ карам. Това ще бъде c:\ диск на моя лаптоп. Аз съм гледам над рамото ми през цялото време, така че никой не ще ме питат, "защо вие сте спасим този работен поток към вашия лаптоп?"

Невероятно, Това решава проблема ми. Мога да редактирам задача.

Аз с настоящото номинира това да бъде най-странни поток заобиколно решение на 2007.

</край>

Ние често искат да изпратите имейл, който съдържа хипервръзка към елемент или документ, което стартира работния поток. Ние можем да използваме текущия елемент "Кодиран абсолютен URL адрес" за тази цел. Въпреки това, Тя винаги изглежда да се използва "http" за URL Протоколът. Ако вашия сайт се изпълнява на HTTPS тогава тя няма да работи за вас.

Доколкото знам, там е никакъв вън на кутия решение на този проблем. Ако трябва да използвате HTTPS, Вие нямате от опция.

Да го решим, създаване на потребителско действие, което предоставя низ замени функция да се използва във вашия работен поток. Алтернативно, Използвайте трета страна инструмент като отличен пакет тук: http://www.codeplex.com/spdwfextensions 🙂

</край>

Форум на потребителите понякога питат: Защо does слагам SharePoint Designer ???? в моя имейл вместо стойност на поле?

Една причина, това се случва, е, защото тази променлива, за която говорите е null.

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

<край />

Сценарий: В SharePoint Designer поток, Вие трябва да определите дали поле за дата е празно.

Проблем: ЕДП не предоставя директен метод за сравняване на дати за нищо друго освен дата. Не можете да създадете условие подобен този: "Ако [DateField] е равно на празни".

Разтвор: Преобразуване на дата в низ. Използвайте сравнение на низове, за да определи дали датата е празно.

Снимки на екрана:

Следните снимки на екрана показва как да направите това. В този сценарий, поле на елемент, "Екологични разрешителни:Първо разрешително за дата за напомняне", е подадена и работния поток пожари в отговор.

Бележки:

Когато се опитах това, Аз бях приятно изненадан да научи, че тя работи. Бях притеснен, че SharePoint Designer може да забраните присвоената низ (Променлива:StringReminderDateDate) но тя го позволи.

Също така бях отнася това което му позволява, стойността може да бъде null и двете взриви WF по време на изпълнение или може би повишаване на глобалната температура 1/2 степен, но тези опасения са основателни.

</край>

Просто бързо наблюдение, че има много важна разлика между тези две дефиниции:

<FieldBind поле = "InParam1" DesignerType = "StringBuilder" ИД = "2" Текст = "Въвеждане параметър # 1" />

срещу:

<FieldBind поле = "InParam1" ИД = "2" Текст = "Въвеждане параметър # 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 ви позволява да създавате на низ (очевидно) чрез смесване низ числа, както и данни на работния поток (чрез "Добавяне търсене" бутона в долния ляв ъгъл). Когато използвате бутона за добавяне на търсене, Вмъква маркер във формуляра"[%маркер %]". Когато SharePoint извиква вашето потребителско действие, (C# код в моя случай), SharePoint минава маркер за самия, не стойността на маркера. Ако използвате дизайнер тип по подразбиране (Вторият тип), SharePoint се разширява маркера и действителната стойност на маркера, преминава към си действие.

StringBuilder = ЛОШО, по подразбиране дизайнер тип = добър.

Разбира се, Това е не това, което наистина искам. Само не се опитвайте и мине параметър към вашето потребителско действие, когато дизайнерът тип = StringBuilder. Използвайте дизайнер типът по подразбиране и верига StringBuilder да го отпред, ако имате нужда да изгради комплекс низове във вашия работен поток (която между другото е точно какво от един да се създаде динамична тема на имейл действие, но това не е предмет на друг блог запис, Хар Хар).

<край />