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

Играхме с персонализиран формуляр за тази цел, но в крайна сметка, Здравият разум спечели деня и ние просто използват познати <a href = mailto:…> техника. (<a href ризница:…> е изненадващо силен малко HTML; като бонус, тази връзка ме води обратно към дните ми стар човек страници на UNIX; Това бяха дни!).

Тази техника осигурява голям интерфейс за крайните потребители, тъй като те се използват MS Outlook клиента си запознат (или каквото и имейл клиент те са инсталирани).

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

Ние whiteboarded няколко потенциални решения. Любимата ми е на скрито копие (CC) списък на SharePoint. По този начин, крайният потребител все още получава клиента на outlook, докато стигнем до улавянето на събитието, защото ние ще получите копие на имейл себе си. Има някои очевидни недостатъци. Основният проблем е, че потребителят може да просто празен, или по друг начин маш CC адрес. И, Ние трябва да управляват това събитие библиотека на имейли. Имаме планиран проект на бяла дъска, отговорен за тази почистване.

Ако имате някои умен подход към решаването на този проблем, Моля, кажете.

</край>

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

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

Като запитания и обещаните, Аз бях качил моята презентация за това как да се получи "Велики" изисквания от крайните потребители на SharePoint проекти и реализации. Тя е тук: HTTP://CID-1cc1edb3daa9b8aa.SkyDrive.Live.com/Self.aspx/SharePoint/Paul Galvin Great Requirements.zip

Аз това представени на конференцията SharePoint най-добрите практики в февруари 2009 (www.sharepointbestpractices.com). Ако присъстваха конференция, също така ще получите това на конференцията DVD.

Презентацията включва много бележки с повечето слайдове. Това не е само куршум точки.

(Вижте тук за моята презентация на управление казус: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</край>

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

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

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

Тази седмица, Трябва да решим проблем на бизнес, който мисля, че ще станат по-чести, тъй като компании отпуснеш и да възприеме по-пряка краен потребител контрол над SharePoint. В този случай, Аз проектирани сайт шаблон за подкрепа на специфични крайния потребител Общността. Хора в тази общност трябва да бъде в състояние да създават свои собствени сайтове на воля, като използвате този шаблон, когато настояват удари ги.

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

Така, Аз я включите, Опитайте го и за мен, Тя не създава сайтове. Тя е създаване на сайт колекции. Доста голяма разлика. Това е не това, което искам, Съвсем не.

Това е възможно да уведомите крайните потребители създават нови подсайтове чрез ниво на потребителски разрешения. Това е точно къде щях да отида на първо място с изключение, че етикетът "създаването на самостоятелен сайт" етикет ме излъга. Чрез twitter, I learn that it’s deceived others as well 🙂

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

</край>

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

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

Аз бях един от 20 или 30 (или може би 100?) съдебните заседатели снощи в Ню Йорк група на SharePoint потребители събрание. Вместо обичайните презентация формат, Това е всичко за Q&А между публиката и членовете на групата. В началото на, Майкъл Лотер въведени ми към нова идея и аз исках да споделя.

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

"Какви са моите опции? Не искам да запазите отдаване потребители влезте директно в сървъра, но те се нуждаят от тази функционалност."

Michael Лотер предполага, че той конфигурирате нова виртуална машина, Присъединете се към него в стопанството като WFE и позволяват на потребителите да стартирате приложението от там.

Това е доста невероятна идея за мен. Обобщаващи това решение носи напомня за идеята на по същество временно, почти еднократна WFE. Мисля, че това е доста чист концепция. Тази временна WFE да стартирате конзолата за кандидатстване, която използва обектния модел на SharePoint. Можете също да го използвате за изпълнение на команди stsadm. Тя не трябва да бъде част от редовните местни балансиране. Ако тя отива надолу или получава разбиха, Можете просто да върти една нова. Аз се повтаря, но аз просто трябва да кажа, че аз мисля, че това е наистина чист идея.

</край>

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

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

Миналата седмица, някой зададе въпрос за създаване на среда на SharePoint, който да се справи доста голям обем на нови документи (10,000 +/- в този случай). Аз не знам много за това, Но Благодарение на тази бяла книга, Аз се чувствам много по-добре информирани.

За мен, Настоящата Бяла книга е доста много просто книга марката в момента, но did трепвам четене през нея и си помислих, аз ще изтъкне моята основна по домовете. SharePoint може да бъдат мащабирани за обработка, най-малко, това натоварване:

• 50к нови документи на ден.
• 10 общо документи.

Аз пиша 50k/10 мм цифрите, защото те са достатъчно лесни за запомняне. Като знаете, че те са минимуми, Вие няма да получите в беда. Максимуми са най-малко 10 процента по-висока от това и с екстремни тунинг, вероятно много по-високи.

Благодаря, Майк Уолш, веднъж за неговото Седмичен WSS FAQ актуализации и корекции след. Ако не сте се абонирали за него, Вие трябва да сериозно да мисля за да го прави.

</край>

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

През изминалата седмица, Моят колега и са прави някои работи за един клиент в Ню Йорк. Бяхме тества различни аспекти на Мос прилагането им "стандартен" изграждане на станция (за разлика от нашите лаптопи). Докато правите това, Ние се блъсна в няколко грешки, като следвате тези стъпки:

• Отваряне на MS word документ чрез windows explorer (която използва WebDAV).
• Направете промяна.
• Запишете го.

Ние дойде да осъзнават, че някои пъти (обикновено за първи път) Ние записани документа, Запиши не "стик." Запиши не спаси. Ние би дръпнете този документ обратно и нашите промени просто не са били там.

Не разбирахме корен въпрос в този момент, но ние помислихме, че ние трябва да сте сигурни, че на последния сервизен пакет MS Office е инсталирана на тази работна станция. ТО народ отиде и че. Минахме през теста отново и ние открихме нов проблем. Когато ние го записали, Ние сега имам тази грешка:

Този път, Той изглеждаше като всяка промяна е, Всъщност, записани, дали сме отговорили или не на скриптове въпрос.

Ние най-накрая имах поглед към актуалната версия на Office и се оказва, че работното място е действал MS Office 2000 сервизен пакет 3 което показва под помощ-> За като "Офис 2002 г.".

Поуката от историята: Аз винаги ще използва Office 2003 като ми минимални основните офис версия при използване на WebDAV и Мос.

</край>

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

(С цел търсене двигател, Това е текст на грешката):

Линия: 11807

Чар: 2

Грешка: Обектът не поддържа това свойство или метод

Код; 0

URL АДРЕС: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

Искате ли да продължи изпълнението на скриптове на тази страница?

В една или ми първи блог постове, Описах процеса ние следва да мигрират на клиент от SPS 2003 на Мос. Читател остави коментар кандидатства за повече подробности и тук е.

За този миграционен проект, Ние трябваше да се намери добър начин да се движат много SPS 2003 документи над на Мос. Първоначалното натоварване е лесно достатъчно. Създайте нова библиотека за целевия документ в мъх и използвате windows explorer, за да преместите документи.

Това е новата библиотека с документи:

Отвори два прозореца изследователи. Точка първа в SPS 2003 а вторият в новата библиотека с документи в MOSS. Следните екрана изстрел показва това. Обърнете внимание, че Топ браузъра всъщност се сочи ми c:\Temp диск, но можете да си представите това, сочещи към SPS 2003 Библиотека с документи:

След това плъзнете и пуснете операция, Целта ми изглежда така:

Сега е време да се справят с метаданни. Приемем, че имаме само една колона на метаданните за тези документи, наречена "местоположение." Можем да видим от по-горе "всички документи" че мястото е празно. Лесно е достатъчно, за да използвате изглед на лист данни, за да въведете местоположение, или дори да отидете в свойствата на документа всеки един по един да добавите местоположение. Нека приемем, че няма практически начин да присвоите на местоположение колона стойност автоматично и че крайните потребители трябва да направите това на ръка. Освен това, да предположим, има стотици документи (може би и хиляди) и че това ще отнеме много много дни за актуализиране на метаданни. Както всички знаем, никой няма да седне и да работят за четири от пет дни направо актуализиране мета данни за документи. Вместо това, те ще че избухне в продължение на седмици или евентуално по-дълго. За да се улесни този процес, Ние можем да създадем "немаркирани данни" Изглед както е показано:

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

Като потребители етикет документи, те капка на разстояние от този списък.

Това понятие за изглед немаркирани данни също могат да помогнат с клас данни ратифицирам проблема хора запитване за форуми. На кутията, няма начин да попречите на потребител да качите документ на Мос и след това не влезе мета данни. Да уточним, че конкретен сайт колона е задължителна и потребителят няма да бъде позволено да натиснете Запиши бутон. Въпреки това, Ако потребителят качи и след това се затваря браузъра (или използва windows explorer за качване на документ), Ние не може да сила на потребителя да въведе мета данни (отново, на кутията).

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

</край>

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

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

Конфигурацията на крайната ферма:

• SQL/индекс/интранет WFE вътре в защитната стена.
• WFE в DMZ.
• Някаква защитна стена между DMZ и вътрешния сървър.

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

1. SSL означава ви трябва сертификат.
2. DMZ сървърът трябва да бъде част от домейн.

Един ден, Ние се появи да инсталират МЪХА и научих, че не е бил създаден акаунтите на домейна за база данни и Мос. За да се движат нещата напред, Ние went напред и настанявам всичко с локален акаунт на сървър, интранет.

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

Един уикенд течение и клиента получава сертификат.

Нашата инфраструктура човек показва и открива, че DMZ сървърът не е присъединен към домейн (периметър домейн с ограничено доверие или домейн интранет). Ние губи почти 1/2 деня, в който. Ако не оставим липсващите SSL сертификата ни блато, Ние ще са открили това по-рано. О добре….

Друг ден преминава и различните комитети, сигурност, заинтересовани страни и (не е така) невинни минувачи всички са съгласни, че това е ОК, за да се присъединят в DMZ сървър с домейна на интранет (Това е Рос, Все пак, не на производството решение).

Инфраструктурата човек идва, за да приключи нещата. Този път, ние успешно преминават през съвременните ръкавицата предано, известна като "съветника за конфигуриране на SharePoint." Ние имаме един поглед в централното администриране and … Иии haw! … DMZ сървър е в списъка в земеделското стопанство. Ние изглежда малко по-близо и реализира Скъсахме отворен Шампейн акар малко рано. ВиК услуги се заби в "Начална" статус.

Дълга история кратко, Оказва се, че сме забравили да промените самоличността на акаунта на услугата чрез централната администрация от оригиналния мастен сметка към новия домейн акаунт. Ние го направихме, отново се завтече на съветника за конфигуриране и готово! Ние бяхме в бизнеса.

</край>

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

Въпреки че това не е буквално вярно, на практика, Интернет ориентирана уеб клиент в DMZ трябва да бъде в домейн (т.е.. не някои самостоятелен сървър в своя собствена малка работна група). Тя не трябва да бъде в същия домейн като вътрешен WFE(s) и други сървъри (и вероятно не трябва да), но той трябва да бъде в домейн.

Колегите ми и аз изразходвани прекален размер на време въз основа на предложение, което включва SharePoint предпоставки. Това включва подробен списък на защитна стена конфигурации, която би позволила на DMZ сървъра да се присъединят към групата и така нататък. За съжаление, Ние не успя да добави изречение някъде, каза, за ефекта, "цялата кървава точка на тази конфигурация е да разрешите DMZ WFE сървър, в домейн, да се присъединят към вътрешния ферма."

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

Въздишка.

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

Форум на потребителите често като въпроси като този:

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

SharePoint осигурява някои от функциите на кутия, които поддържат видове бизнес изисквания като че.

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

Използвайте допълнителни списъци, за да запази номера на клиенти, продукти с номера, н.

Използвайте уеб компонент на заявка за съдържание (в мъх само) и/или данни за преглед в уеб компонента за създаване на обединени изгледи на списъци. SQL Server услуги за отчетност (SRS) е също наличен за докладване от страна на това.

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

• Размер на свързаните lookup списъци срещу. "интелигентност" от справочен тип колона. Справка колоната тип се представя на потребителския интерфейс по различен начин в зависимост от това дали сте активирали многократен избор или не. И в двата случая, контролата за вън на на кутия показва всички налични елементи от списъка на източника. Ако списъкът източник има 1,000 елементи, Това ще бъде проблем. Контрола за справка не страница през тези елементи. Вместо това, всички от тях дърпа в контрола. Това прави за много неудобно потребителски интерфейс за въвеждане на данни и изпълнение.
• Заявки "дърпам обратно" една колона информация. Вие никога не може да тегли обратно повече от една колона на информация от списъка източник. Например, не можете да изберете даден клиент "12345" и покажете номера, както и името и адреса на клиента в същото време. Търсене само показва на клиента номера и нищо друго. Това прави за неудобно и трудно потребителски интерфейс.
• Intra-форма комуникация. Аз съм писал за това тук. Вие не може да реализира каскадни падащите, условно разрешаване/забраняване на полета, н.
• Без каскадно изтриване или вградени целостта. SharePoint третира потребителски списъци като независими образувания и не ви позволяват да ги свържете помежду си в традиционния смисъл на ERD. За пример, SharePoint ви позволява да създадете две потребителски списъци, "клиент" и "фактура заглавка". Можете да създадете заглавен блок на фактура която свързва обратно към клиент в списъка на клиенти. След това, Можете да изтриете клиента от списъка. На кутията, няма начин да се предотврати това. За решаване на този род на проблема, Вие обикновено ще използвате манипулатори на събития.

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

• Манипулатори на събития. Ги използват за целостта на данните.
• Колони по избор: Създаване на типове потребителски колони и да ги използват вместо по подразбиране справочна колона. Добавяне на виртуална памет, непълно буфериране и Аякс функции за да отговарят.
• BDC. Тази само за Мос функция ни позволява да заявка за други SharePoint списъци с чувствате потребителски интерфейс към обичайните справочна колона. BDC също може да достигне до задния край сървър приложение. Използвайте КБД, за да се избегне репликация. Вместо възпроизвеждането клиентска информация от задния край ERP система, Вместо това използвайте на BDC. BDC функции осигуряват приятен потребителски интерфейс да дръпне тази информация директно от системата ERP, където принадлежи и избягва караница за поддържане на репликация решение.

  BDC е Мос функция (не е налично в WSS) и е предизвикателство за конфигуриране.

• ASP.NET уеб форма: Създаване на пълнофункционални AJAX-активирани формуляр, който използва модел и/или уеб услугите на SharePoint обект да се наберат списъци на SharePoint, като същевременно осигурява много отзивчив потребителски интерфейс.

Последният вариант може да се чувствате като сте се започне от нулата, Но предвид факта, че платформата SharePoint ти започва със следните основни характеристики:

• Модел на сигурност с поддръжка.
• Менюто система с поддръжка.
• "Главната таблица" (т.е.. потребителски списъци) със сигурност, вградена поддръжка и проверка.
• Търсене.
• Инструменти за интегриране на задния край (BDC).

Ако започнете с нов празен проект в visual studio, имате много на инфраструктура и ВиК да изгради преди да стигнем до това, което SharePoint предлага.

Аз вярвам, че Microsoft възнамерява да разшири SharePoint в тази посока на разработка на приложения. Тя изглежда като естествено продължение на база съществуващата SharePoint. На Microsoft CRM приложение осигурява голяма част от разширяване на типовете, необходими да подкрепят горен/детайл приложение развитие. Въпреки че тези функции са в CRM, технологията е очевидно наличен на SharePoint развитие екип и аз очаквам, че ще направи своя път в SharePoint продукт от края на 2008. Ако някой има знания или вникване в това, Моля, оставете коментар.

</край>