Аз написах една статия за SharePointBriefing.com и те го постави живо днес.

Тук е закачка:

Проверете го.

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Аз съм бил работи по проект, когато трябва да екстракт прикачени файлове от формуляр на InfoPath. Има някои добри ресурси за анализиране на формуляри на InfoPath (които са само XML файлове, така че това е всъщност доста лесно).

Докато е изграждането на проекта, Започнах като изтегляне на формуляр на InfoPath и го запишете на моя локален твърд диск. Моят c# код е четене директно от тази инстанция. Въпреки това, формуляри на InfoPath са наистина живеят вътре в библиотека с формуляри на SharePoint. Направих малко половин сърце търсене, за да разберете как да го прочетете директно от библиотеката и почти се отказах, в този случай бих записали формуляра на локална temp директория и го прочете от там. Въпреки това, не е необходимо да мине през тези обръчи, както можете да го прочетете директно от библиотеката. Този малък откъс показва как:

/// Клас определение неща тук, включително:

частни SPFile mySharePointFile; /* Част от списъкът */

// Още код отива тук и вътре метод на класа имаме:
XmlTextReader textReader;

textReader = нов XmlTextReader(mySharePointFile.OpenBinaryStream());

textReader.WhitespaceHandling = WhitespaceHandling.Няма;

textReader.Read();

// Ако възелът е стойност

докато (textReader.Read())
{

Те ключови малко по-горе е, че можем да прочетем InfoPath директно чрез OpenBinaryStream() метод викам на SPFile като параметри на конструктора на XmlTextReader. То работилница голям.

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Имам решение за влизане сметка за клиент, който лостове InfoPath и поток. В един момент по време на процеса на одобрение, Трябва да генерира имейл, който има всички тези добри данни InfoPath, както и прикачените файлове, самите така че (въздишка) някой може да вземе тези данни и ръчно повторно ключ то в приложение за база данни Oracle.

Не е много трудно да получите в или разбор на формуляра на InfoPath. Аз не знам как да се справят с прикачени файлове, Въпреки това. След един час или два изпълзяват около Internets (вечност!) Аз намерих тази статия: http://support.microsoft.com/kb/892730

Той предостави някои удобен код, за да извлечете прикачения файл от един възел под формата. (Вие все още трябва да се намери възел и всичко това, но това е просто XML разбор).

Знам, че прикаченият файл е base64-кодирани и първоначално отидох по пътя на просто извличане на base64 данни, Това декодиране и го запишете. Въпреки това, Бързо разбрах, че аз не знам как да получите името на файла, самата, докато намери гореспоменатия член.

Аз действително е установено, че доста рано, но аз бях поставени на разстояние от своята раздвоение на личността. От една страна, член * казва, * то е добро за InfoPath 2007. Още, на кодекс и инструкции са всичко за Visual Studio 2003 и позоваванията на InfoPath 2003.

Долната линия, код на този член при условие работи добре за мен (досега). Мога да получа моя формуляр на InfoPath, Може да го анализира, Мога да намеря и декодира прикачения файл и аз знам името му. Какво повече може един да поиска от живота?

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

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

Имам сметка одобрение процес, който трябва да се прилага с помощта на InfoPath във формуляри, базирани на удостоверяване (FBA) среда с помощта на форми услуги (уеб базирани InfoPath).

Има две групи, одобрение и процесът работи като този:

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

В InfoPath страна на нещата, Имам различни секции, които скриване/се появяват въз основа на това дали потребителят е член на една от тези групи, одобрение.

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

Аз не добавите всички допълнителни колони към списъка.

Когато формулярът се отваря, има правило като този:

"Задаване на стойност на поле" е тук:

Това е основно казва: Заявка за одобрение група потребителски списък и филтър, който заявка по примера за всеки ред къде дял на стойност = "Северни".

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

Затворете кръга чрез осигуряване на отделните елементи в списъка група за одобрение. По време на изпълнение, Ако текущият потребител няма има право на достъп до този елемент тогава заявката няма да го върне, дължина на низ ще бъде нула и сега знаете текущият потребител не е част от тази група. Можете да използвате този факт, както е необходимо под формата.

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

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

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Аз работех по форма на InfPath днес и се натъква един стар приятел, "Необработено изключение при рендиране форма System.Xml.XmlException: Неочакван край на файл при анализа Име възникна."

Това ми се случи преди много време и аз не знам какво точно направих да го разреши. Честно, Мисля, че е бил преход към нов проект и никога не видях този един решен (Моят заместители трябваше да се справят с това главоболие). Аз си спомням беше дявол на проблем. Прекарах няколко неуспешни дни, занимаващи се с него. Оттогава, Аз съм виждал това идват на MSDN форуми най-малко веднъж през миналата година и не видях отговор за него.

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

В моя случай, Проблемът е причинен от тези стъпки:

1. Добавяне на нов елемент към източник на данни в текстово поле.
2. Пуснете върху формуляра.
3. Променете го на дисплея в падащия списък.
4. Кажете на падащия списък да дръпнете си стойности от потребителски списък на SharePoint.

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

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Аз съм все още живеят в света на формуляри на InfoPath и трябва да се направи една от тези "малки" промени към формуляр,, за съжаление, почивки именуване конвенция се приемат с него преди две седмици. Мислех за себе си, "някой ще изглежда в това, което една година от сега и казват, "Какво е Пол мислене? Дявол да го вземе, неговата именуване конвенция няма смисъл!”

Аз осъзнах, че мога да създавам Изглед във формуляра за това и след това, Още веднъж, осъзнах, че аз може да са били прави нещо като това през цялото време. Добавих "Разработчик бележки" изглед за InfoPath форма като такива:

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

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Мога да премине през фази на InfoPath където, на синьото, Аз съм занаяти един куп формуляри. Пръстите ми Научете как да използвате инструмента добре и след това минават през девет месеца суша и трябва да го научите всичко отначало, отново.

Аз съм в средата на фаза на InfoPath и аз съм създаване на формуляри на InfoPath с много пъти видяна. Едно нещо, което вероятно ще забележите е, че InfoPath 2007 Клиент показва изгледи по азбучен ред. Това е истински неудобство няколко пъти. Моят най-добър техника тези дни е да добавя число към името на изгледа, така че те винаги се показват в ред искам, както е показано тук:

Иска ми трябваше този начин всички заедно.

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Аз бях работи върху някои формуляри на InfoPath тази седмица в Мос в FBA среда и учен, Когато отидох да разположи формуляри към производствена среда с FBA зона която потребителското име() функция функция не работи. Аз бях го използва за генериране на уникални файлови имена.

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

Моето решение е да използвате сега() функция и правило, което пожари при зареждане на формуляра. Присвояване името на файла за елемент от данните, когато е празно:

Предимството на този подход е, че името на файла е настроен само веднъж. (Аз не се показват в екрана изстрел, но постави условие на правилото да само огън, когато "myFilename" е празно). Аз използван за да зададете името на файла на ниво данни източник. Обикновено, Ще направя нещо (Лош) Ето така:

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

Така, като досадно като FBA може да бъде по принцип и с InfoPath в частност, Тя ме прави мислите отново с малък, но много важни технически подробности и подход, който няма да са направили по друг начин!

</край>

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

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

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

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

Този пример за office.microsoft.com в статията се описва как да създадете отделна "Изглед" и маркирате целия изглед само за четене. Това е един работещ подход, но има недостатък, че ефективно сте създали две цяло версии на същата форма и трябва сега да ги синхронизирате ръчно. Ако добавяте поле към изгледа за редактиране, след това трябва да го добавите към нередактируемо изглед, както и. С течение на времето, с различни разработчици, може да има някои различия.

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

• Добавяне на ново поле на формуляра, наречен "IsEditable".
• Задаване на стойността по подразбиране на true.
• Тя насърчава, при публикуването на МОС.
• В работния поток, Задаване на стойността на IsEditble на false.
• Назад към формуляра.
• Добавяне на правило което "при отваряне на формуляра", забрани, бутона за вашия запис, когато IsEditable е неистина.

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

В един проект, Създадох състояние на работен поток "" изглед. Тъй като работния поток напредна, то ще update специфичен статус полета, които е повишен от формуляра. Когато потребителят отвори формуляра, "отвори формуляра" правило превключила автоматично в изглед и потребителят да е хубаво малко резюме статус.

</край>

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

Имахме развита на формуляр на InfoPath с множество изгледи в подкрепа на ново под наем / процес на качване на борда. Когато фирмата наема нов човек, ИТ отдела и други групи трябва да се предприемат действия (настроите ТРЗ, разрешаване на достъп до подходящи приложения, Намерете бюро, н). Ние използваме на форма но различен изглед на формуляра за всяка от тези функции.

В тази фирма, Повечето от хората, участващи в процеса на бизнес са ИТ-разбирам, така че, когато те имат достъп до формуляра, Изгледът им по подразбиране е "меню" Покажи с бутони, които ги насочват към тяхната специфична функция. Въпреки това, Ние трябваше да опрости нещата за нови автомобили пряк ръководител. Този човек не трябва да видите някоя от ИТ, свързани неща. Всъщност, Тя трябва да види само един изглед на формуляра и дори имате възможност да видите други изгледи.

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

Стъпките са както следва:

1. В режим на проектиране, отидете на инструменти-> Опции за формуляр-> Отваряне и запис.

2. Изберете "правила".

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

потребителско име() връща "прост" потребителско име без домейн. Ако аз влезли в SharePoint с идентификационни данни "domainpagalvin", потребителско име() връща "pagalvin".

Селектор на контакта осигурява три бита на информация за контакт. "AccountID" част е най-полезна за този сценарий. Единственото нещо, което прави това дори малко предизвикателство е, че избора на контакт (в моята среда все пак) Връща ID на домейна и потребителското, както и в "domainpagalvin". Това ни пречи да го състояние равенство прав напред от AccountID ("domainpagalvin") ще никога не е равно на потребителско име() ("pagalvin").

Ние може да получи около това, като използвате "съдържа" оператор: AccountID съдържа потребителско име().

Ние може да отнеме това допълнително и предварително-pend закодирани домейн предната част на име() функция, за да получите нашите равенство проверка и премахване на риска от фалшиво положителни за съдържа оператор.

Ще имаме наистина като за автоматично превключване на изглед за други потребители, въз основа на техните рекламни сигурност група членство. За пример, Когато член на "го анализ" група получава достъп до формата, автоматично превключи към изглед на IT анализ. Ние не са имали време да го приложат, но първата ми мисъл е да се създаде уеб услуга, която ще има метод като "IsMemberOfActiveDirectorySecurityGroup", Подай потребителско име() и да се върнете обратно true или false. Някой има ли някакви други, по-умна идея? Е там кой да е SharePoint функция ние може да лоста от InfoPath, за да направи това определяне?

</край>