В този пост разглеждам как работят формите на списъци и Content Types в SharePoint 2007 (в случая WSS v3) и какви са ни възможностите за разширяване и разработка. В тази първа част ще обясня как да използваме наши си ASPX форми, а във втора – как да заменим стандартните Rendering Templates с нови. С втория пост ще сложа и линк към решение с пример за двата варианта.

Когато създадем списък в SharePoint, ние всъщност създаваме копие на базата на съществуващ шаблон – List Template. Тези шаблони са дефирнирани в Features, и всеки Feature с шаблон за списък ще съдържа дефиниращ файл: schema.xml. Този schema.xml може се разгледа за всеки списък, който WSS v3 ни предлага: разгледайте 12\TEMPLATE\FEATURES папката, там има Features като CustomList, ContactList, DocumentLibrary. Всичките имат schema.xml, който дефинира особеностите им.

В края на този XML (CAML) файл може да видим „Form” елемент, който дефинира ASPX страниците, които ще бъдат използвани за списъка, на който схемата принадлежи.

Когато се създава списък, платформата прави копие на файл-а дефиниран в “SetupPath” атрибута на “Form” елемента, и го качва в базата данни с посоченото име в “Url” атрибута. След като страницата е създадена (това е обикновен Web Part Page), SharePoint слага ListFormWebPart в посочения WebPartZoneID. “pages\form.aspx”, и подобни други ASPX страници се намират в 12\TEMPLATE\Pages, и там можете да сложите своите. Горният screenshot е от CustomList, но можете да разгледате и всички останали.

Интересното става, когато Content Types са добавени в списъци. Всеки Content Type може да има свои DisplayForm, EditForm или NewForm зададени, а всеки списък може да има множество Content Types. Съответно за създаването на различен вид съдържание в един списък можете да имате различни форми за различните Content Types – това е много добра гъвкавост. От друга гледна точка, всеки Content Type може да има един и същ интерфейс (форма) навсякъде, когато е използван многократно.

Как работи всичкото това зад сцената?

В SharePoint SPContentType обектът ни позволява да му зададем EditFormUrl, DispFormUrl, и NewFormUrl (притежания):

cType.EditFormUrl = "_layouts/ourprojectfolder/customedit.aspx";

cType.NewFormUrl = "_layouts/ourprojectfolder/customnew.aspx";

cType.DisplayFormUrl = "_layouts/ourprojectfolder/customdisplay.aspx";

Ако тези са дефинирани от нас, SharePoint прави следното:

· С избирането на “New” бутона или съответните опции от менюто на всеки ред в списъка, SharePoint ни праща на EditForm.aspx, NewForm.aspx или DispForm.aspx според избора.

· Когато създава списъка, платформата конфигурира ListFormWebPart на всяка от тези ASPX страници (откопирани са от Pages\form.aspx). WebPartZoneID атрибута определя къде точно да се добави този Web Part. Тези страници не могат без този Web Part – SharePoint се оплаква ако се опитате да го насочите към страница без ListFormWebPart.

· Този ListFormWebPart проверява текущия SPControlMode (Edit, New, Display), и дали съответното притежание (EditFormUrl, DispFormUrl, или NewFormUrl) на текущия Content Type е зададен. Логиката може да бъде проследена ако разгледаме кода на този web part – в OnInit метода се прави проверка на притежанието this.FormPageUrl, което всъщност е obfuscated и не мога да ви го покажа.

Независимо дали е зададен от нас или не (EditFormUrl, DispFormUrl, или NewFormUrl), SharePoint ни праща към съответната страница - NewForm.aspx, EditForm.aspx или DispForm.aspx. На тези страници ListFormWebPart проверява текущия Content Type (всеки List Item в SharePoint има зададен Content Type) и ни препраща към съответната форма (ако тя е зададена от нас). this.FormPageUrl определя коя е тя на база на текущия SPControlMode (New, Edit, Display), но не мога да ви покажа кода на this.FormPageUrl защото е obfuscated. Така всъщност става конфигурирането на поризволни форми.

Проблемът на този дизайн, е че SharePoint първо ни праща към NewForm.aspx (или една от другите) и след малко код отново ни препраща чрез SPUtility.Redirect (което зад сцената е по-украсен Response.Redirect). Това са два post-back-a, и можете да ги проследите с Firebug или Fiddler, или който и да е друг HTTP listener. Освен, че препратките са две, NewForm.aspx е Web Part Page, а те не са хич леки.

Това, което все още не знам е как да конфигурираме EditFormUrl, NewFormUrl или DispFormUrl в схемата на ContentType елемента (чрез CAML). Примерът по-горе е чрез код и обектния модел, но той не е идеален за всички случаи. В WSS v3 “Form” елемента е “obsolete”, така че начина, по който го правихме в WSS v2 е вече невалиден. Втория ни вариант всъщност е да работим с XmlDocuments елемента в CAML – той ни позволява да сменим съответния Rendering Template на формата. Така става чрез CAML, но двата метода работят по коренно различен начин.

Във втората част на този пост ще разгледам как да заменим стандартните Rendering Templates с произволни, и съответно алтернативния вариант да разширяваме формите на списъци и Content Types.

Надявам се това ще помогне на някой.

This post is the first out of a two-part series, where I look at the way SharePoint list forms work and how we can customise them. Part 1 explains how to use custom ASPX pages for list forms, and Part 2 goes through replacing SharePoint’s default rendering templates with custom ones. At the end of the activity I will provide a code sample with both.

When we provision a list in SharePoint we make an ‘instance’ of it based on a list template. Templates are defined in features, and each feature with a list template will hold a schema.xml file. You can view the schema.xml files of existing list templates in features that come with WSS – CustomList, ContactList, DocumentLibrary, etc. just check the 12\TEMPLATE\FEATURES folder.

At the bottom of the schema.xml files we can see a Form element that defines the ASPX files used during the provisioning of lists:

When a list is provisioned, the platform makes a copy of the physical file defined in the “SetupPath” attribute, stores it in the content DB and names it as specified in the “Url” attribute, and adds a ListFormWebPart to the WebPartZoneID specified. “pages\form.aspx” maps to 12\TEMPLATE\Pages\form.aspx and you could replace these with your own. I have demonstrated CustomList, but other lists and libraries use the rest of the files in there.

All this gets interesting when Content Types are added to lists. Each Content Type can have its _own_ DisplayForm, EditForm or NewForm – and in a single list you can have different forms for different Content Types - This means POWER! Furthermore, the same Content Types used across different lists can have consistent forms.

So how does it work?

The SPContentType class allows you to set the EditFormUrl, DispFormUrl, and NewFormUrl properties:

cType.EditFormUrl = "_layouts/ourprojectfolder/customedit.aspx";

cType.NewFormUrl = "_layouts/ourprojectfolder/customnew.aspx";

cType.DisplayFormUrl = "_layouts/ourprojectfolder/customdisplay.aspx";

If these are set, this is what happens under the hood:

· The “New” button on the toolbar or the Item Context menu takes the user to one of the forms: EditForm.aspx, NewForm.aspx or DispForm.aspx

· During provisioning, the ListFormWebPart is added to each of these forms. Check the WebPartZoneID property – this tells the platform where to add the web part. You can’t go without it – SharePoint complains.

· The ListFormWebPart checks the current SPControlMode (Edit, New, Display) and whether the respective property of the current item’s Content Type is null or empty. This can be seen by examining the source code of the web part with Reflector. It makes a check on this.FormPageUrl (which is obfuscated!):

So what we can see is the navigation items take us to either NewForm.aspx, EditForm.aspx or DispForm.aspx. The ListFormWebPart on that page does a check on the current Content Type and takes us to the current SPControlMode’s form. This is what “this.FormPageUrl” does behind the “obfuscated” scene.

An obvious drawback of such design is the fact that the user is first taken to NewForm.aspx (or any of the others), then an SPUtility.Redirect call is made (essentially Response.Redirect) which results in a second postback for the user. You can see the two requests with Firebug or any other HTTP listener. Apart from that there is some overhead – NewForm.aspx is a web part page (and they aren’t light).

What I currently don’t know is how to set the EditFormUrl, NewFormUrl and DispFormUrl properties in the ContentType definition schema. The “Forms” element is obsolete in WSS v3, so the only current way I know to change forms via CAML is to work with the XmlDocuments element. These two options work in a completely different manner. In Part 2 of this series I will demonstrate how you can set custom rendering templates in features with content types.

Hope this helps.

С появата на Visual Studio 2010 Beta и вградените инструменти за разработване на SharePoint решения, някои активни представители на SharePoint dev общността се съюзиха да съставят extensions за VS, които улесняват нашата работа. Това, което MS предлага, е много добро и страхотно подобрение от инструментите за SP 2007, но винаги има и място за допълнение от community-тo.

Community Kit for SharePoint: Development Tools Edition е колекция от новите open-source инструменти събрани в едно. Waldek Mastykarz е много активен блогер, MOSS MVP и страхотен SharePoint dev, който много уважавам. Wouter van Vugt е човека, който ми предаде материала за SP Ignite Training 2010 и ме подготви да се кандидатирам като потенциален преподавател за България. Очаквам само добри неща от тези хора, и разбира се от останалите, които допринасят за CKS: Development Tools.

Линк: Community Kit for SharePoint: Development Tools Edition (CKS:DEV)

(Благодаря на Веско за проверката!)

Ето Ви линк към пълният код от събитието: SharePointBG.PM.Full.zip

Скриптовете имат хард-коднат път – C:\Projects\SharePointBG.PM.

Ще Ви трябва WSPBuilder за да можете да отворите решението в Visual Studio.

Презентацията и документа можете да ги намерите на този блог пост: SharePoint Development Days Jan 2010

Ако имате въпроси, не се колебайте да ми пишете.

Поздрави!

Благодаря, на всички които успяха да дойдат! Събрахме се 18 човека в зала за 15 души (:

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

В началото на деня разказах за решението, което ще разглеждаме, как ще го деплойваме, и защо. На кратко разгледахме как SharePoint отразява бизнес обекти и как да създаваме такива. Декларативният CAML за някой беше нещо ново, но успях да покажа как самият SharePoint си създава свойте сайтове и списъци. Разгледахме и създаването на Site Templates, и как те пакетират нашите компоненти.

Благодарение на Мартин (от Абилитикс) обядът също беше успешен (:

Във втората част от деня погледнахме и web parts и тяхният life-cycle. Продължихме с Application Pages. Показах и малко C# код, но не стигнахме до създаване на custom controls и писане на CAML queries ):

Според мен деня мина добре, аз лично съм доволен и успях да се запозная с всички. Материала може би беше малко advanced за тези, които не са работили много с SharePoint. Visual Studio ми създаде проблеми, но те не пречиха на прогреса (евентуално причинителят беше WSPBuilder…).

Надявам се, всеки взе нещо със себеси, което може да го използва в бъдещите си проекти!

Презентацията можете да си я изтеглите от следния линк: NHBG_SharePoint_BG.ppt

Задачите, които приготвих: SharePointDevelopmentDaysJan2010.doc

Решението и кратко описание ще намерите на този линк: Code from SharePoint Development Days Jan 2010 

Сега започвам да правя планове по следващото събитие… надявам се отново да се видим!

Ради А.

Снощи на SUGBG срещата се зададе този въпрос. Отговора е, че перформанс-а е по-добър и възможностите за скалируемост са значителни. Ето го директно от блога на екипа на SharePoint в Microsoft: http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx

Q: Why are you only supporting the 64-bit versions of SQL Server 2005 or 2008 for SharePoint Server 2010?
A: This decision was based on our current test data for SharePoint Server 2010 and real world experience from customers running SharePoint Server 2007 with 32-bit SQL Server.  SharePoint performance and scalability can benefit significantly from 64-bit SQL Server and the throughput increases are significant enough for us to make the difficult decision to only support SharePoint Server 2010 on 64-bit SQL Server 2005 or 2008.  It has been our strong recommendation for some time that SharePoint Server 2007 customers take advantage of 64-bit SQL Server due to the inherent performance and scale benefits it can provide.

Q: Where can I find more information on the advantages of 64-bit hardware and guidance on how to migrate SharePoint from 32-bit to 64-bit.
A: These two TechNet articles are a good starting point;

Advantages of 64-bit hardware and software (Office SharePoint Server 2007)

Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

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

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 проекти, абсолютна отговорност е на консултанта да обясни тези неща.

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

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