Radi Atanassov

SharePoint MCM, MVP, MCT and owner of OneBit Software

Microsoft Days 2010 – код и PowerPoint Slides

За мен това беше първият MS Days на който съм присъствал - бях супер доволен. Добра атмосфера, много партньори, добри лекции… дори имаше и бира ?!?!?

Лекцията, която изнесох беше най-техническата на тема SharePoint – искаше ми се да има повече SharePoint (:

Ето и кода, който обещах: PerformanceManagement.zip

Това, за което може да ви е полезен е:

  1. Добавяне на бутон в Ribbon на SharePoint 2010
  2. Link към custom javascript file за този бутон
  3. отваряне на диалогов прозорец с т.н. Dialog Framework
  4. SP2010 webpart, който генерира Office документи с Open XML и Word Automation Services – супер интересно (:
  5. Има и един web service в SP 2010

Ето и презентацията: MS Days Radi Atanassov

Аз лично бях доволен от лекцията, въпреки че забравих да покажа генерираните PDF и XPS files…

Ето го и рейтинга ми:

Ради Атанасов

Архитектура и изграждане на бизнес приложения с SharePoint 2010, Silverlight и Open XML SDK (Ниво: 300)

79

Oбща оценка на презентацията

7.85 / 9

Ради Атанасов

Архитектура и изграждане на бизнес приложения с SharePoint 2010, Silverlight и Open XML SDK (Ниво: 300)

79

Компетентност на лектора

8.08 / 9

Ради Атанасов

Архитектура и изграждане на бизнес приложения с SharePoint 2010, Silverlight и Open XML SDK (Ниво: 300)

79

Предоставената информация е полезна за моята работа

7.46 / 9

Ради Атанасов

Архитектура и изграждане на бизнес приложения с SharePoint 2010, Silverlight и Open XML SDK (Ниво: 300)

79

Презентационни умения на лектора

7.54 / 9

Поздрави!

Използване на LINQ to XML върху резултатите от SharePoint Web Services

Когато работиме със Silverlight имаме възможност да използваме LINQ to XML за извличане на данни от резултатите от SharePoint Web Services. Тези дни разгледах LINQ to XML и никога повече не бих работил с XmlDocument обектите (:

Ето няколко примера:

GetListItems() – това е метод от Lists.asmx, и ето му отговора:

<listitems xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema"
xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<rs:data ItemCount="13">
   <z:row ... ows_ContentType="Task" ows_Title="New Task 1" ... />
   ... more rows here
</rs:data>
</listitems>

За да извлечем заглавията на list items и да ги подредим в List<string> обект:

private List<string> ProcessListResults(SPListsWS.GetListItemsCompletedEventArgs e)
{
    string result = e.Result.ToString();
 
    XNamespace ns = "#RowsetSchema";
    XElement results = new XElement(e.Result);
 
    var listItems = from x in results.Descendants(ns + "row")
                    where x.Attribute("ows_Title") != null
                    select x;
 
    List<string> itemsList = new List<string>();
 
    foreach (var item in listItems)
    {
        string title = item.Attribute("ows_Title").Value;
        itemsList.Add(title);
    }
    return itemsList;
}

GetUserInfo() – Този метод е от usergroup.asmx и ни дава информация за user в текущия SPSite обект (взима го от скрития user list). Ето отговора:

<GetUserInfo xmlns="http://schemas.microsoft.com/sharepoint/soap/directory/">
  <User ID="7" Sid="S-1-5-21-347908140-582334945-263120918-1111" Name="Radi"
    LoginName="DEV\radi" Email="" Notes="" IsSiteAdmin="False"
    IsDomainGroup="False" />
</GetUserInfo>

 

И как извлиам LoginName:

public static string GetLoginFromServiceResponse(XElement result)
{
    XNamespace ns = "http://schemas.microsoft.com/sharepoint/soap/directory/";
 
    XName xUser = XName.Get("User", ns.NamespaceName);
    XName xUserInfo = XName.Get("GetUserInfo", ns.NamespaceName);
 
    XElement user = result.Element(xUser);
 
    if (user != null) {  return user.Attribute("LoginName").Value; }
 
    return null;
}

Това което подавам на метода е “e.Result.ToString()” от отговора.

Очаквайте още!

Using LINQ to XML to process SharePoint web service responses in Silverlight

Since working with LINQ to XML, I’ve totally fallen in love with it and could never go back to working with the XmlDocument objects.

Here are a few code snippets that can help you out. It is so simple once you get a hang of it.

GetListItems() – this Lists.asmx method returns the following response:

<listitems xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema"
xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<rs:data ItemCount="13">
   <z:row ... ows_ContentType="Task" ows_Title="New Task 1" ... />
   ... more rows here
</rs:data>
</listitems>

To get the value of the title into a List<string> object:

private List<string> ProcessListResults(SPListsWS.GetListItemsCompletedEventArgs e)
{
    string result = e.Result.ToString();
 
    XNamespace ns = "#RowsetSchema";
    XElement results = new XElement(e.Result);
 
    var listItems = from x in results.Descendants(ns + "row")
                    where x.Attribute("ows_Title") != null
                    select x;
 
    List<string> itemsList = new List<string>();
 
    foreach (var item in listItems)
    {
        string title = item.Attribute("ows_Title").Value;
        itemsList.Add(title);
    }
    return itemsList;
}

GetUserInfo() – this method is inside usergroup.asmx and gives us information regarding a user in an SPSite object. The response:

<GetUserInfo xmlns="http://schemas.microsoft.com/sharepoint/soap/directory/">
  <User ID="7" Sid="S-1-5-21-347908140-582334945-263120918-1111" Name="Radi"
    LoginName="DEV\radi" Email="" Notes="" IsSiteAdmin="False"
    IsDomainGroup="False" />
</GetUserInfo>

 

To get the LoginName:

public static string GetLoginFromServiceResponse(XElement result)
{
    XNamespace ns = "http://schemas.microsoft.com/sharepoint/soap/directory/";
 
    XName xUser = XName.Get("User", ns.NamespaceName);
    XName xUserInfo = XName.Get("GetUserInfo", ns.NamespaceName);
 
    XElement user = result.Element(xUser);
 
    if (user != null) {  return user.Attribute("LoginName").Value; }
 
    return null;
}

The passed in “result” is derived from e.Result.ToString().

Hope this helps!

SharePoint meets LINQ to XML: CAML заявки за работа с Lists.asmx

Напоследък ми се налага да работя с LINQ to XML за интеграционни сценарии включващи Silverlight и SharePoint. LINQ to XML е страхотно – сравнително по-добре от създаване на XML чрез обекти като XmlDocument.

Ето пример – повиквам GetListItems() метода на Lists.asmx. Със следният код извличам list items от Task списъка създадени от специфичен user. Този пример би трябвало да работи както за WSS v3, така и за MSF v4.

XElement query = new XElement("Query",
        new XElement("Where",
            new XElement("Eq",
                new XElement("FieldRef", new XAttribute("Name", "Author"), new XAttribute("LookupId", "True")),
                new XElement("Value", new XAttribute("Type", "User"), userID)
)));


XElement queryOptions = new XElement("QueryOptions");
XElement viewFields = new XElement("ViewFields");

_listService.GetListItemsAsync("Tasks", null,
    query, viewFields, "100", queryOptions, null, null);

userID e SharePoint ID-то на потребителя, за който искам да видя резултатите. Можете да получите тази информация от usergroup.asmx.

Успех!

SharePoint meets LINQ to XML: Building a CAML Query and calling Lists.asmx

I’ve been playing around with LINQ to XML and Silverlight recently, and it is absolutely awesome! The amount of code you have to write compared to working with XML DOM objects like XmlDocument is extremely minimised.

Here is an example on calling the GetListItems() method of Lists.asmx. I am returning the top 100 items in a Task list that are created by a particular user. This code example should be compatible for both WSS v3 and MSF v4.

XElement query = new XElement("Query",
        new XElement("Where",
            new XElement("Eq",
                new XElement("FieldRef", new XAttribute("Name", "Author"), new XAttribute("LookupId", "True")),
                new XElement("Value", new XAttribute("Type", "User"), userID)
)));


XElement queryOptions = new XElement("QueryOptions");
XElement viewFields = new XElement("ViewFields");

_listService.GetListItemsAsync("Tasks", null,
    query, viewFields, "100", queryOptions, null, null);

userID is the SharePoint user value within the current SPSite. You can get this with the usergroup.asmx service.

Hope this helps!

CKS: Development Tools - Съвместни усилия за нашето community

С появата на 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)

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

Защо SharePoint 2010 изисква 64-bit SQL?

Снощи на 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 Ignite Training - Петък

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

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 - Петък

 

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 - Петък

SharePoint 2010 Ignite Training - Сряда

Програмата за Сряда беше пълна с неща, които ме интересуват поради задачите които поемам на работа. Въпреки пийването предишната вечер бях много ентусиазиран по първата тема – 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 - Петък