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

SharePoint 2010 има едно ново понятие “Sandboxed Solutions”. Денят започна с разглеждането на този нов тип пакет съдържащ решението. Sandboxed Solutions са решения, които работят под отделен, сигурен процес. Sandbox средата ни позволява да сме сигурни, че кодът който пускаме в фермата няма да засегне елементи извън сайт колкцията в която се пуска. Тази среда също ни гарантира, че некачествен код няма да засегне цялата ферма – процесът под който работи тази среда ще се погрижи да предотврати проблеми. Администратори могат да конфигурират ресурсите, с които Sandboxed Solutions разполагат – много интересна функционалност.

Всичките тези качества и предимства си идват с цена – има граници на възможностите на едно Sandboxed решение. Една от тези е, забраната на решението да качва файлове в 12 hive-a (14 hive…). Това има смисъл, тъй като решението трябва да работи в пълна изолация, а всичко в този hive е споделяно с цялата ферма. Друго ограничение е самият обектен модел е съкратен – не се работи с нищо над SPSite, а самият SPSite обект е създаван от околния процес и такъв не може да се създаде от програмист – само се употребява на готово. Повиквания към SPSecurity обекта съшо са забранени.

Работа с Sandboxed Solutions ще предаде много добри знания за всеки .NET developer, тъй като решението работи под CAS, и като разработчици ще трябва да се вмъкваме в позволимите заявки и методи. Истина е, че много малко разработчици пускат своя код под CAS policies.

След лабораторно упражнение денят продължи с една много добра лекция на тема Security в SharePoint 2007. Woulter ни припомни как всъщност работи SharePoint от гледна тояка на права. Разгледахме системните акаунти под които работят SharePoint процесите, и ролята на SHAREPOINT\System акаунта (господ). Разгледахме и ACL моделът на SharePoint 2007.

Всичко това беше супер въведение към промените, които SP2010 носи със себе си. В 2010 целият модел е променен с по-модерен Claims-based Security Model. Това е нов модел на права в .NET Framework 3.0, който в случая с SharePoint 2010 отделя SharePoint от зависимоста с своя authentication provider. WSS беше зависим от Windows AD провайдера, или от Forms Based Authentication на .NET. Ползите са много, например поддържането на повече от един authentication provider за един URL (спомняте си extend web application за FBA и конфигуриране на интернет сайт за редактиране от AD потребители), и предаването на идентичност без конфигурирането на Kerberos delegation.

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

Обсъдихме и възможностите за разширяване – създаване на свой провайдер на claims. Сценария на интегриране между SharePoint и Live authentication ще е интересен.

 

Следващата тема беше на тема ъпгрейд на код от предишна версия – отново нещо, за което съм много емоционален. Вижте този блог: Цената на upgrade – не я пренебрегвайте!

Първото нещо, което разгледахме е възможноста за import на решения от VSeWSS – това е add-in за Visual Studio 2008, който така и не излезе от CTP. Проекти за 2007 ще могат да бъдат ъпгрейдвани за Visual Studio 2010, но това не гарантира по никакъв начин, че решението ще работи. Структурата на решението се запазва – същите features ще ги получите.

Много съм развълнуван от поддръжката на SharePoint решения в Visual Studio 2010. В новите SharePoint типове проекти интерфейса предлага feature designer и package explorer – два инструмента, които улесняват работата с пакетирането на едно решение.

Вобще не бях впечатлен от идеята за Visual Web Parts – това не е нищо ново. Visual Web Part е template с ASCX control, в който има 3 реда код който зарежда този ASCX control в обикновен web part. Това го имаше и в 2007. Новото е, че IDE-то наистина улеснява създаването, но от гледна точка на SharePoint няма нищо ново. Тази функционалност трябваше да бъде първото нещо, което показват на Visual Studio 2010 conference, а не на SharePoint Conference 2009 (: Всияко, според мен, е чист маркетинг с цел промоция на SharePoint development. Добър ход от Майкрософт – те целят именно това, и са го измислили по ефикасен начин – маркетингова операция без много необходимост от промени дълбоко в ядрото на SharePoint.

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

·         STP файлове няма да могат да се ъпгрейдват – вобще не ме е жал за консултанти, които ги използват – много ги мразя.

·         Промените в user interface на SharePoint – макар, че има backwards compatibility interface, ако искате да ъпгрейднете решението като хората ще трябва да поработите по CSS и самия markup.

·         На новият обектен модел може да липсват методи, които ползвате

·         Научих и че код, който се повиква от timer jobs трябва да бъде прекомпилиран

·         Код, който работи с SSP (SSP е премахнат)

 

Със сигурност има и други неща...

Последната тема от цялото събитие – Application Lifecycle Management. Може би най-полезният урок за разработчиците. Цялата тема беше изпълнена с upgrade, test, trial, fix сценарии. SP2010 предлага подобрения, които правят разработването на проекти по life-cycle модел по-възможни.

На първи фокус беше визията за съвместна работа между инструментите за работа – SharePoint Designer 2010, Visio 2010 и Visual Studio 2010. Когато краен потребител редактира сайт, може директно от браузера да се отвори SharePoint Designer 2010 в контекст, и да се продължи от там работата. След редактиране, един сайт може да се запази като WSP template и да се премести за работа в Visual Studio 2010 – невероятна функционалност. Разработчик може да го поеме и да продължи работата. От VS2010 може да се качи и в Source Control (TFS), и от дам да се качи в тестова среда. Всико е така направено, че да има логична последователност и възможност за цялостед development lifecycle.

Самите features вече поддържат и версии, нещо което не работеше в 2007. Версиите на features поддържат и зависимости между други features – може да се конфигурира, така че версия 2 на даден feature да се нуждае от версия 5 на друга. Ще ми е интересно да разгледам и опитам тази функционалност по подробно – аз лично правя upgrade програматично и ще е новост за мен. Дано ми спести време.

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

Аз останах до Неделя, да мога да преразкажа всичко което научих и да поразгледам Берлин. Чуден град, чудесна бира...

 

Линкове към останалите дни:

SharePoint 2010 Ignite Training - Понеделник
SharePoint 2010 Ignite Training - Вторник
SharePoint 2010 Ignite Training - Сряда
SharePoint 2010 Ignite Training - Четвъртък
SharePoint 2010 Ignite Training - Петък

 

Започнахме четвъртия ден от трейнинга с разглеждането на новостите в ECM дяла на SharePoint 2010. Подобренията в тази сфера според мен за ужасно важни поради следните причини:

·         Силни функции в ECM ще позиционира SP2010 на по-висше ниво спрямо конкурентските платформи на IBM и Oracle, и ще помогне на SP2010 да навлезе по-дълбоко в enterprise сферата

·         В ECM влиза и document management, едно от най-често срещаните приложения на SP2007, всяко подобрение там е значително. В България (не само) едно от първите приложения на SharePoint в една компания са с цел управление и съхранение на документи.

·         В ECM влиза и WCM, което би засилило използването на SharePoint като платформа за интернет страници.

·         Като предишен работник в консултантска фирма, фокусираща се предимно в ECM пространството, недостатъците на SP2007 са нещо много познато за мен. Те са малко, но често съм се сблъсквал с пречки и силно се интересувам от новостите. На всичките си бивши ECM проекти вече мога да предложа нещо по атрактивно и функционално.

 

В първата част от ECM темата разгледахме WCM. За съжаление не ми направи впечатление, че новостите са много – всичко изглеждаше като подобрения на съществуващи функции. Повечето са свързани с новият интерфейс и fluent начин на работа:

·         Директното редактиране на съдържание на самата страница

·         AJAX прозорци вместо post-backs

·         Самият asset picker е подобрен – сега е лесно да се намерят картинки и се интегрира с т.н. Asset Library за лесно качване на картинки от компютър

·         Ribbon за познато и предсказуемо място на командни бутони

·         По-добър Rich Text Editor

·         Майкрософт целят самия HTML markup да е по стандарти (W3C).Според мен, единствено може да правим коментари по тази тема, когато излезне версия за пазара.

Това, което ми направи впечатление от техническа гледна точка, е че Pages библиотеката вече поддържа папки. В 2007 липсата на папки беше проблем когато един сайт има много страници – в списъците в 2007 беше препоръчително броят на обектите да е под 2000, а като нямаше папки ситуациите с повече страници водеше до проблеми. Това, което не разбрах, е дали “Pages” библиотеката може да се преименува. Някой фирми не искат “Pages” в самите URL’s на страниците си (разгледайте ASP.NET Url Rewriting за да преодолеете този проблем).

Моят любим Content Query Web Part също е преминал през upgrade. Вече поддържа филтриране на данните на база на query string параметри, или параметри на текущата страница. Това не беше възможно в 2007 и изискваше разработване. До колкото разбрах, в самият интерфейс може и да се посочват метаданните, които заявките да връщат. В 2007 това беше възможно само чрез редактиране на CommonViewFields параметъра в самият .webpart file. Нямам търпение да разгледам XSLT file-овете и как те са се променили.

Друга новост свързана с WCM е Web Analytics услугата. Това е Service Application за статистики относно употребата на сайтовете, което в MOSS2007 беше слабост. Дава ви добра видимост върху трафика, най-популярните страници, search ключови думи и т.н., и пакета предлага “What’s Popular” web part, който дава възможност тази информация да се представи и на крайните потребители. Интересно е.

Oт гледна точка на чист ECM, най-значително е Enterprise Content Types и Managed Metadata Service. Целта на Enterprise Content Types е да се дефинира един тип един път, и да се преизползва многократно в фермата, в различни сайт колекции. Единственият начин да се постигне това в 2007, така че да е напълно еднакво навсякъде и да се създадът само един път, е чрез feature, който се деплойва на всеки site collection. Сега Managed Metadata Service се грижи за синдикиране на content types, термини и keywords които се използват в системата. Един сайт може да има Enterprise Content Types и локални Content Types, като тези които са Enterprise са read-only. Това е полезно за бизнеси, които всъщност имат дефинирани процеси и обекти на работа. За бизнеси, които тепърва си подреждат информационната архитектура, тази функционалност може да бъде добър инструмент за подпомагането на тази задача, но само ако бъде изполвано рационално.

Направило ми е впечатление, че употребата на content types в България е много слабо, поне в проектите, които съм виждал. Това според мен се дължи на непознанието на ползите от такава функционалност на самите консултанти. Вие ползвате ли content types във вашите решения? Инструменти, като Best Practice Analyzer for SharePoint няма да посочат, че решението Ви не използва content types – чисти бизнес ползи от едно решение, както и нивото на употреба на едно решение, не могат лесно да се измерват с инструменти. За мен там е разликата между добрите консултанти, и чистите разработчици. Стига съм мрънкал...

 SharePoint 2010 има и подобрения от гледна точка на фолксономия и таксономия (taxonomy & folksonomy) – системата поддържа tags и keywords. Tags са на enterprise ниво – синоними, превеждане, дефинирана структура – а keywords са произволен текст от крайните потребители. Тази функционалност е нова за SharePoint и предполагам мотивацията е да се засили SharePoint в social media сферата, както и отново по-добър ECM. Много добър ход.

Идеята за Record Center вече не е толкова стриктна. Функционалноста е разделена на features, които могат да се преизползват навсякъде в системата. Съществува идеята за “In Place Records Management” – всеки обект или документ може да се маркира като „архив“ в самото място, където се намира. Няма нужда да бъде изпращан в Records Center. От това ще следват интересни решения.

Новост е понятието за Advanced Routing – крайни потребители нямат нужда да мислят къде да качват документи, а системата преценява на тяхно място на базата на правила. SP2010 предлага Drop Off Library за тази цел. Това не беше възможно в 2007 без разработване, а е често срещано изискване защото OpenText HummingBird работи по подобен начин. Разработвали сме такъв проект, а сега всичко е почти част от продукта L

Научих и, че в SP2010 е въведена функционалноста на Document Sets – групирани документи свързани с общ предмет на работа. Като пример мога да дам договор, с всичките документи с които той е свързан (скици, анекс, приложения), да бъдат свързани в пакет и да се движат заедно в системата. Според мен това е полезно, и има ситуации, в които ще е идеална функционалност. Това което не можах да разбера и запомня, е как работят версиите в Document Sets, ще трябва да го проуча допълнително.

Още нещо ново, което сигурно всички сме разработвали, или в SharePoint или в CRM – Unique ID service. Едно от най-често срещаните изисквания в ECM е уникално номериране на документи. В нашата бюрокрация един документ има по няколко номера... Сега SharePoint предлага Service Application специално за тази цел – уникално номериране на документи в една сайт колекция. Добре де, защо не е уникално за цялата ферма? Нека да видим кой пръв ще пусне такова решение на codeplex... Това, което научих, е че Document ID-то може да му бъде конфигурирана схемата и формата, но не го разгледахме. Ползата, че може да се генерира линк директно към документа, независимо от неговото местоположение. Ако документа се премести, линка е един и същ. Изглеждаше така: http://<portal>/ _layouts/DocIdRedir.aspx?ID=<myprefix>1-1-1. За нас разработчиците имаме обект, който може да наследим: Microsoft.Office.DocumentManagement.DocumentIdProvider – Забележете namespace-a...

 

За съжаление, следващата тема не видяхме много от нея – Search. Проблема е, че FAST Search компонента, който е вече част от SharePoint Server, не работеше на версията, която разглеждахме. Темата за Search беше само приказки. Това, което ми направи впечатление, е че Search ще си дойде с connectors за други системи като Documentum, OpenText HummingBird, Filenet и Exchange. Имаше голями подобрения относно архитектурата, и ако не се лъжа системата за Ranking може лесно да се променя.

 

Денят продължи с разглеждането на BI възможностите на SharePoint. Продукта предлага нови web parts за визуализиране на информация, като най-впечатлителния е Charting Web Part. Самият web part изглеждаше много гъвкав и мисля, че ще свърши работа. Забелязах, че този web part няма нужда от Excel Services – това ще улесни работата ни. Интересно ми е как седят нещата от гледна точка на лицензиране. Ще чакаме резултати. (друго интересно и точно в мой стил – дали самият деплоймент е лесен? Както винаги, искам деплоймент с 1 стъпка (:... )

Разгледахме и PerformancePoint Services, който е част от SharePoint Server. Самите dashboards са наистина впечатлителни... Много бяха шаренки... Поддържаха се всякакви модерни функции като drill-down, filtering, grouping, etc. Инструментът, с който се създават вече се казва Dashboard Designer, в момента не се сещам как се казваше първата му версия. Този инструмент е насочен по към IT Pro хората отколкото девлопери, и отново не разбрах как се разработва решение с този инструмент, така че да е част от жизнения цикъл на проекта (design-develop-test-deploy). До колкото разбрах се прави разработване на самата крайна среда – това за мен е чисто ПРЕСТЪПЛЕНИЕ и трябва да се промени този начин на работа!

BI Search – нещо ново, и сравнително интересно. Част от Enterprise версията и FAST Search, тази функционалност дава възможност на Search завки да връщат резултати с линкове директно в справки. Тъй като FAST не работи, това беше преразказано от Woulter и не си поиграхме вобще.

За Excel Services най-впечатляващото беше извличане на информация от Excel чрез REST API’s Може директно да се задъде линк към графика в Excel, и тя да бъде върната като картинка директно годна за браузера. Супер. Excel данни също могат да се изкарват в web parts, като в тази версия те са по-гъвкави и с по-добри възможности. Друго интересно беше самият Excel Viewer – Web базиран Silverlight браузер за Excel workbooks. За това малко повече по-нататък.

Линкове към останалите дни:

SharePoint 2010 Ignite Training - Понеделник
SharePoint 2010 Ignite Training - Вторник
SharePoint 2010 Ignite Training - Сряда
SharePoint 2010 Ignite Training - Четвъртък
SharePoint 2010 Ignite Training - Петък

Мойте съвети за всеки, който възлага проект към консултантска фирма:

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

·         Кой е лидерът на проекта, който отговаря за цялостния процес, комуникация и project management?

·         Кой е архитекта, отговорен за техническата посока и качество на изработка? Той в състояние ли е да води екипа и има ли техническите познания?

·         По колко други проекта работи всеки един от участниците? Имате право да знаете.

·         От предложението на консултантската фирма, ясен ли е процесът на работа? Той включва ли прототип, анализ на бизнес изискванията, документ който ги потвърждава, фази на проекта, план за тестване и премахване на бъгове, реалистични срокове? Гаранция?

·         Какви сертификати има фирмата и работниците по проекта? Това е спорно изискване – всеки може да има ISO 9001 и MCP сертификати, и работата пак да е некачествена. За мен тези неща не показват знания и опит, но показват дисциплина – някой се е захванал и отделил време да свърши една работа. Хубаво е, когато това е систематично – ако всичко е реализирано в близки дати, най-вероятно е постигнато за определена цел, като спечелването на определен проект.

·         Готови подобни решения – консултанта има ли такива? Обадете им се, попитайте ги как се чувстват относно решението. Доволни ли са от цялостният процес и ангажиране? Това може да се струва коварно на някой, но е често срещана практика в чужбина. Всеки има право да знае.

·         Качество на документите на консултантската фирма – това показва колко е организирана една фирма, и колко сили полага в изглаждането на детайли. Разгледайте офертите и предложенията – има ли правописни и граматични грешки, документа форматиран ли е добре, добре ли описва темата на комуникация? Вобще личи ли си професионализъм, или работата е джаста-праста?

·         Попитайте фирмата дали ще има подизпълнители. Имате право да знаете, но ако има ситуацията се усложнява. Кой е отговорен за какво? Зависими ли са всичките участници?

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

Ради Атанасов
Консултант, архитект и разработчик на SharePoint решения.

Една от най-важните качества за всяка нова версия на всеки нов продукт е начина на ъпгрейд от предишна версия. Същото се отнася и за внедрени решения на която и да е платформа. Целта на нови версии на софтуер е да носят нови възможности от които модерният бизнес се нуждае. Системи с които се интегрира едно решение също може да се нуждаят от подновяване, или дори нов хардуер. IT светът е много динамичен, няма спор. Искам да си кажа мнението за цената на ъпгрейд и как един текущ проект задължително трябва да вземе тази цена в предвид.

Много компании не предвиждат цената на подновяване на едно решение. Сблъсквал съм се с клиенти, които се интересуват от пълната цена сега на момента, и винаги гледат тя да е най-минилана, като се отстраняват всички допълнения към един проект освен директната разработка. Но ако не се вземе в предвид цената на подновяване и променяне в бъдещето, да кажем след година, тази цена е напълно безсмислена. Според мен всяко решение трябва да бъде създадено с мисълта за ъпгрейд, разширяване и подновяване. Трябва да има документация, качествена архитектура, МНОГО качествен код, план за възстановяване след дизастер и всичко да е минало през пълноценен тест –именно тези неща се пренебрегват. Всичкото това струва пари, но добрият управител трябва да му е наясно защо се правят тези неща. Ако един мениджер не му е ясно и няма опит с IT проекти, абсолютна отговорност е на консултанта да обясни тези неща.

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

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

Програмата за Сряда беше пълна с неща, които ме интересуват поради задачите които поемам на работа. Въпреки пийването предишната вечер бях много ентусиазиран по първата тема – Client Object Model – тъй като в Абилитикс разработваме наш продукт с thick client. SP2010 предлага 3 нови библиотеки за комуникиране от външен процес/програма:

·         Microsoft.SharePoint.Client.dll – обекти за работа от custom проложение, което достъпва данни в SharePoint

·         Microsoft.SharePoint.Client.Silverlight.dll – обектен модел за работа със Silverlight

·         SP.js – JavaScript интерфейси

До колкото запомних, всички новости по-горе комуникират с Client.svc (WCF Service), който директно работи с обектите в Microsoft.SharePoint.dll. Този слой от клиентски обекти би улеснил работата на всеки разработчик и се надявам да поработя с някой от новите неща в най-скоро време.

Майкрософт е направила така, че имената на обектите, както и тяхните методи да са едни и същи във всички библиотеки. “SP” представката, обаче, е махната... Web вместо SPWeb, List вместо SPList…

От девелопмент гледна точка, за да се работи с модела се започва с ClientContext обект. Той се грижи за изпращането на XML заявки към Client.svc, който връща отговори в оптимизирани JSON.

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

Като партньор на Nintex, втората тема също ми беше много интересна – Workflows в SP2010. Вече се поддържат и workflows на ниво Сайт, а не само на List Item като в 2007. Може би най-впечатлителната нова функция е визуализирането на процеса в Microsoft Visio 2010, след което готовият резултат може да се препрати към SharePoint Designer. Оттам може директно да се модифицира и публикува в SharePoint. От  SharePoint Designer  може и да се export към Visual Studio 2010 за работа от програмисти и разрешаване на по- сложни изисквания. Според мен ефекта е наистина значителен и работата с workflows ще се улесни – в момента това е на сложно ниво. Сега може да създаваме прототип на процеса в Visio 2010, да го прехвърлим в SPD за реализиране и деплоймент към SharePoint. Друго интересно нещо е преносими workflows – в 2007 се създаваха SPD workflows за специфичен лист – сега може да се създават “Reusable workflows”, надявам се това да няма скрити недостатъци. Интересувам се, и от възможността да прехвърлим workflow от 2007 в 2010. Дали има възможност да се запази текущата инвестиция?

Вече смятам, че решения със SharePoint Designer ще са реални – самите workflows са преносими. Това дава възможност за включването на разработката на workflows в цялостен development lifecycle, което до сега не беше възможно за workflows в SPD. Експорт към Visual Studio 2010 съвсем показва, че Майкрософт ни чува като мрънкаме – аз лично съм много доволен. Инвестицията в SPD 2010 изглежда голяма, има ribbon interface, workflow дезайнера е съвсем нов, възможностите са много повече.

Последната тема за деня също беше супер – новият Services модел в SP2010. Целият application/services layer на SP2007 е с нова архитектура. В SP2007 SSP-то беше супер, но имаше някой недостатъци относно гъвкавост и скалируемост. SSP в 2007 трябва да предлага всички услуги (search, BDC, users, Excel) и специфичните web applications бяха обвързани към специфично посочени SSP’s. Отделно, SSP’s не бяха лесно разшираеми с разработване.

В SP2010 всеки service е отделен компонент, и може услугите да се конфигурират на отделни application сървери. Това ще даде възможност на сценарии, които имат нужда от load balancing за специфичен service. Примерно, може да се създаде услуга, която да работи на независим сървер дедикиран за тази услуга – workflow engine, external data service, analytics, data synchronization, etc. Услугите могат и да се споделят между отделни ферми, може да създадете ферма изцяло за хостване на услуги – нещо, което би било ценно на enterprise ниво.

Новото нещо, което за малко да ме свали от стола, е че Services модела е вече част от WSS, или т.н. SharePoint Foundation 2010. Това е невероятно за България, защото WSS решенията са много на брой, и проникваемостта на SharePoint в нашия пазар ще е засилен. Отделно – BCS (BDC) на WSS ниво – power!

Комуникациите стават чрез WCF интерфейси, но самият Service не е чисто WCF Service.Това, което ние разработчиците създаваме, е самият Service Application, който се инсталира и пуска на всеки сървер по избор. На всеки service трябва да се създаде и интерфейс за администриране – пускане, конфигуриране на акаунти, информация за custom database, ако има такива – това ознава, че ние разработчиците трябва да владеем и административния API. До колкото разбрах, задължително е и разработването на методи за provisioning и чрез PowerShell, което вкарва и PowerShell в картинката. Ако не сте на „ти“ с WCF, време е да прелистите книгата на Juval Lowy (нали няма нужда да посочвам коя е?).

Линкове към останалите дни:

SharePoint 2010 Ignite Training - Понеделник
SharePoint 2010 Ignite Training - Вторник
SharePoint 2010 Ignite Training - Сряда
SharePoint 2010 Ignite Training - Четвъртък
SharePoint 2010 Ignite Training - Петък

Регистриране на Event Receiver за Content Type в Feature с XmlDocument... всичко звучи като по учебник, до момента в който не се усетите, че сте забравили NamespaceURI.

В документацията на XmlDocument пише следното:

NamespaceURI

Optional Text. Specifies the URI to the schema namespace for the contents of this XmlDocument element.

 

Ами не е точно optional… Ако този Feature е дефиниран за активиране от Site Definition, и се пробвате да създадете сайт на база на Site Definition-a, получават се много интересни забележителности: CPU на 100%, SQL поглъща всичката памет (не че имам много...) и всички услуги са неизползваеми. User interface-а не показва нищо друго, освен екрана за чакане, а през това време зад сцената става армагедон.

Ето и малко CAML:

  <ContentType ID="0x0101006BD6DAD38F7947799A6F2EE72F5C3C11"

             Name="Test Content Type"

             Group="Custom Content Types" Version="0">

    <FieldRefs>

      <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" />

    </FieldRefs>

    <XmlDocuments>

      <XmlDocument>

        <spe:Receivers xmlns:spe="http://schemas.microsoft.com/sharepoint/events">

          <Receiver>

            <Name>UniqueNamingEventReceiver</Name>

            <Type>ItemUpdated</Type>

            <SequenceNumber>10000</SequenceNumber>

            <Assembly>SUGBG.Website.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=205b31e1c60edcc4</Assembly>

            <Class>SUGBG.Website.UniqueNameReceiver</Class>

            <Data></Data>

            <Filter></Filter>

          </Receiver>

        </spe:Receivers>

      </XmlDocument>

    </XmlDocuments>

  </ContentType>

 

И ето дефинирането в Site Definition Site Features елемента (това е в ONET.XML):

      <SiteFeatures>

        <!-- Test Content Type -->

        <Feature ID="11BFEA71-1C5E-4A24-B310-BA51C3EB7A1" />

 

Интересно е, че същият CAML е ок ако feature-a е активиран от менюто в SharePoint.

Eто и дефиницията, която работи:

<ContentType ID="0x0101006BD6DAD38F7947799A6F2EE72F5C3C11"

             Name="Test Content Type"

             Group="Custom Content Types" Version="0">

    <FieldRefs>

      <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" />

    </FieldRefs>

    <XmlDocuments>

      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/events">

        <spe:Receivers xmlns:spe="http://schemas.microsoft.com/sharepoint/events">

          <Receiver>

            <Name>UniqueNamingEventReceiver</Name>

            <Type>ItemUpdated</Type>

            <SequenceNumber>10000</SequenceNumber>

            <Assembly>SUGBG.Website.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=205b31e1c60edcc4</Assembly>

            <Class>SUGBG.Website.UniqueNameReceiver</Class>

            <Data></Data>

            <Filter></Filter>

          </Receiver>

        </spe:Receivers>

      </XmlDocument>

    </XmlDocuments>

  </ContentType>

 

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

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

(за тези, които спорят, че CAML си е чист код... прави са. Заглавието лъже.)