Tworzenie, wdrażanie oraz monitorowanie rozwiązań w trybie piaskownicy programu SharePoint 2010

Autor:Paul Stubbs

SharePoint jest rozbudowaną platformą deweloperską z ogromną wspólnotą aktywnie projektującą rozwiązania. Odwieczny problem, jednak, stanowiła próba utrzymania równowagi między tworzeniem rozwiązań, a wdrażaniem ich w taki sposób, który dawałby pewność, że nie dojdzie do uszkodzenia, ani osłabienia farmy programu SharePoint. Administratorzy farm odpowiadają za utrzymywanie kondycji oraz integralności farm SharePoint. Często oznacza to zastosowanie złożonych, czasochłonnych procesów, w celu przetestowania i dokonania sprawdzenia poprawności rozwiązań wdrożonych w danej farmie. Potrzeba ta pozostaje w sprzeczności z modelem błyskawicznych aplikacji używanym, w celu tworzenia aplikacji SharePoint oraz komplikuje wdrażanie rozwiązań innych firm. Dzięki nowej funkcji w programie SharePoint 2010, o nazwie piaskownica (Sandbox), administratorzy farm mogą być pewni, że farma SharePoint jest bezpieczna, dając administratorom zbioru witryn prawo do zarządzania aplikacjami w swoim zbiorze witryn i zapewniając deweloperom elastyczność w tworzeniu rozwiązań, które będą wdrażane bezpiecznie i błyskawicznie.

W niniejszym artykule opiszę, jak rozwiązania w trybie piaskownicy programu SharePoint 2010 zapewniają strukturę dla bezpiecznego i błyskawicznego wdrażania rozwiązań. Dowiecie się, jak administratorzy farm mogą monitorować rozwiązania oraz jak administratorzy zbioru witryn instalują rozwiązania i funkcje oraz zarządzają nimi. Opiszę również sposób wdrażania składnika Web Part w trybie piaskownicy. Zacznijmy od zrozumienia, w jaki sposób rozwiązania wdrażane są do piaskownicy.

Wdrażanie usług w trybie piaskownicy

Struktura rozwiązań w trybie piaskownicy jest bardzo podobna do farmy, która działa z całkowicie zaufanymi uprawnieniami. Główne różnice polegają na tym, jak wdrażana jest usługa w trybie piaskownicy oraz w procesie, który hostuje rozwiązanie (co decyduje o tym, czy rozwiązanie jest rozwiązaniem w trybie piaskownicy, czy rozwiązaniem farmy). Oznacza to, że to samo rozwiązanie w trybie piaskownicy może być uruchamiane z pełnym zaufaniem, kiedy wdrażane jest na poziomie farmy oraz z częściowym zaufaniem, kiedy wdrażane jest na poziomie zbioru witryn.

Rozwiązanie SharePoint jest możliwym do wdrożenia pakietem, który może zawierać funkcje i zestawy. Pakiet rozwiązań jest plikiem opartym na .cab z rozszerzeniem .wsp. Pliki pakietu .wsp tworzone są przez szablony projektu Visual Studio 2010 SharePoint. Rozwiązanie może zawierać kilka funkcji programu SharePoint, które zapewniają takie możliwości, jak składniki Web Part, definicje listy, moduły oraz odbiorniki zdarzeń.

Obecnie administratorzy zbioru witryn posiadają uprawnienia do przekazywania, aktywowania, usuwania oraz zarządzania rozwiązaniami w trybie piaskownicy przy użyciu nowej funkcji Galerii rozwiązań (Solution Gallery), która jest repozytorium rozwiązań w trybie piaskownicy. Galeria umożliwia również administratorom zbioru witryn monitorowanie użycia rozwiązań wobec przydziału zasobów. (W późniejszej części artykułu pokazane jest w jaki sposób). Galeria rozwiązań jest po prostu standardową listą programu SharePoint, która zawiera plik .wsp. Znajduje się ona w lokalizacji _catalogs folder w _catalogs/solutions. Galeria zostaje dodana do zbioru witryn, kiedy dokonujemy aktualizacji zbioru witryn programu SharePoint 2007. Galerię rozwiązań otwieramy, jak pokazuje Ilustracja 1, najpierw klikając Ustawienia witryny w menu Akcje witryny. Następnie na stronie Ustawienia witryny klikamy Rozwiązania w sekcji Galerie.

Ilustracja 1 Galeria programu SharePoint

Wdrażanie rozwiązania w trybie piaskownicy do zbioru witryn jest tak proste, jak przekazywanie pliku .wsp do galerii i jego aktywacja. Klikając przycisk Przekaż rozwiązanie mamy możliwość przekazania pojedynczego pliku, lub wielu plików .wsp. Kiedy formularz przekazywania pliku otworzy się, należy wyszukać lokalizację pliku, lub plików .wsp, które chcemy wdrożyć.

Następnie, pojawi się monit o aktywowanie rozwiązania. Po dokonaniu aktywacji rozwiązania, automatycznie zostaną również aktywowane funkcje z zakresu zbioru witryn. Jednak aby aktywować funkcje należące do zakresu witryny ze strony Zarządzaj funkcjami witryny, należy przejść do każdej z witryn. Galeria rozwiązań zawiera nazwę rozwiązania, datę modyfikacji oraz status aktywowany i zasoby wykorzystane przez to rozwiązanie. Wykasowanie rozwiązania z galerii możliwe jest tylko po jego dezaktywacji. Aby skopiować rozwiązanie z jednego zbioru witryn do drugiego, należy zapisać plik .wsp na dysku i przekazać do innej galerii rozwiązań.

W celu aktualizacji rozwiązań w trybie piaskownicy, możliwe jest również użycie nowych funkcji infrastruktury aktualizacji rozwiązań i funkcji w programie SharePoint 2010. Aby zaktualizować rozwiązanie, należy utworzyć plik .wsp o nowej nazwie, ale tym samym identyfikatorze rozwiązania. Najłatwiej jest to zrobić poprzez otwarcie projektu w programie Visual Studio i dokonanie zmian, po czym możliwa jest zmiana nazwy pakietu przy użyciu projektanta pakietów. Aby otworzyć projektanta pakietów, w rozwiązaniu dwukrotnie kliknij węzeł Pakiety, a następnie zmień nazwę pakietu. Można już przekazać pakiet rozwiązań w trybie piaskownicy, tak jak byłoby to możliwe w przypadku nowego pakietu. SharePoint wykrywa, że instalowany jest pakiet z takim samym identyfikatorem rozwiązania i wysyła monit o aktualizacji. Po dokonaniu aktualizacji nowa wersja zostanie aktywowana, a stara zostanie dezaktywowana, jak pokazano na Ilustracji 2. Kiedy przejdziemy do składnika Web Part zainstalowanego przez rozwiązanie, zobaczymy uruchomioną nową wersję.

Ilustracja 2 Zaktualizowane rozwiązanie w trybie piaskownicy

Tworzenie składnika Web Part w trybie piaskownicy

Rozwiązanie w trybie piaskownicy wygląda i zachowuje się, jak farma. Jednak aby zestaw rozwiązania w trybie piaskownicy zezwalał na częściowo zaufanych wywołujących, musi zostać oznaczony. Właściwości rozwiązania w trybie piaskownicy konfigurowane są w oknie właściwości projektu. Należy pamiętać, że rozwiązanie w trybie piaskownicy może zostać wdrożone, jako rozwiązanie w pełni zaufane i zyskać poszerzone możliwości, które nadawane są w trybie pełnego zaufania, ponieważ nic w pliku rozwiązania .wsp nie określa go, jako rozwiązanie w trybie piaskownicy, lub farmie. Będzie to zależało od sposobu wdrożenia rozwiązania.

Najpopularniejszymi typami rozwiązań w trybie piaskownicy są składniki Web Parts. W niniejszej części opiszę sposób tworzenia rozwiązania w trybie piaskownicy przy użyciu składnika Web Part i wskażę kilka istotnych problemów. Po pierwsze, w programie Visual Studio istnieją dwa typy składników Web Part—wizualne oraz standardowe składniki Web Part. Wizualny składnik Web Part zawiera formant .ascx, którego można użyć do wizualnego zaprojektowania wyglądu składnika Web Part. Niestety, wizualnych składników Web Part nie można używać w piaskownicy, ponieważ rozwiązania w trybie piaskownicy nie mogą wdrażać plików do frontonu sieci Web, czyli miejsca gdzie pliki .ascx powinny być wdrażane. Oznacza to, że należy utworzyć standardowy składnik Web Part.

Rozpocznij wybierając Pusty projekt w oknie dialogowym w węźle SharePoint dla C#, lub Visual Basic. Kiedy tworzymy rozwiązanie SharePoint, kreator projektu pyta, czy tworzone jest rozwiązanie w trybie piaskownicy, które jest domyślne, czy rozwiązanie w pełni zaufane. (Patrz Ilustracja 3) Tę opcję stosuje się wobec rozwiązań SharePoint, które mogą być wdrażane do Galerii rozwiązań. Kliknij Zakończ po zweryfikowaniu ścieżki do zbioru witryn.

Ilustracja 3 Pole dialogowe nowego Kreatora projektów SharePoint

Aby dodać składnik Web Part, z głównego menu projektu wybierz Dodaj nowy element, a następnie z listy wybierz szablon projektu składnika Web Part. Na tym etapie posiadasz w pełni funkcjonalny składnik Web Part w trybie piaskownicy, który gotowy jest do wdrożenia.

Podczas wdrażania rozwiązania w trybie piaskownicy, po wciśnięciu F5, Visual Studio automatycznie wdraża i aktywuje rozwiązanie w Galerii rozwiązań. Po przejściu do Galerii rozwiązań widzimy rozwiązanie, które właśnie utworzyliśmy i wdrożyliśmy. Na Ilustracji 4 rozwiązanie posiada domyślną nazwę SharePointProject1.

Ilustracja 4 Projekt SharePoint wdrożony do Galerii rozwiązań przez Visual Studio

Podobnie, jak w przypadku innych typów projektów Visual Studio, możliwe jest ustawienie punktu przerwania w kodzie rozwiązania w trybie piaskownicy. Jednakże na tym etapie Visual Studio nie rozpoznaje punktu przerwania, ponieważ składnik Web Part nie został dodany do strony. Jak pokazuje Ilustracja 5, na lewym marginesie linii kodu z punktem przerwania, pojawi się czerwony okrąg wskazujący, że zestaw zawierający składnik Web Part nie został przekazany w załączonym procesie. Po dodaniu składnika Web Part do strony, Visual Studio wykrywa, że zestaw został przekazany i że zatrzyma się na punkcie przerwania. Nawet jeśli do projektu nie został jeszcze dodany żaden kod rzeczywisty, gołym okiem widać, że wszystko jest na swoim miejscu i działa prawidłowo.

Ilustracja 5 Debugowanie rozwiązań SharePoint w programie Visual Studio

Pewna wiedza na temat tego, jak tryb piaskownicy SharePoint jest wdrażany, może pomóc w zrozumieniu, jak debuguje się rozwiązania w trybie piaskownicy. Być może znany jest wam proces debugowania w pełni zaufanych rozwiązań, które uruchamiane są w procesie roboczym programu IIS o nazwie w3wp.exe wykorzystywanego przez SharePoint. Rozwiązania w trybie piaskownicy nie są uruchamiane w tym procesie. Uruchamiają się w procesie roboczym w trybie piaskownicy o nazwie SPUCWorkerProcess.exe, który pokazany jest na Ilustracji 6. Po wciśnięciu F5, Visual Studio automatycznie dołącza debugera do tego procesu. Jeśli debugujemy wcześniej wdrożone rozwiązanie, musimy ten proces dołączyć ręcznie.

Ilustracja 6 Dołącz do procesu SPUCWorkerProcess, aby debugować rozwiązania w trybie piaskownicy

Przyjrzyjmy się teraz kilku przykładom tego, jak działa kod w rozwiązaniu w trybie piaskownicy. Pierwszy przykład zawiera kod, który działa w piaskownicy. Dodaj następujący kod do metody CreateChildControls w składniku Web Part, zaraz po metodzie base.CreateChildControls. Wyraźnie widać, że możliwe jest uzyskanie dostępu do zbioru SPLists, aby zwrócić liczbę obiektów SPList w danej witrynie. Listy i biblioteki w rozwiązaniach w trybie piaskownicy z reguły pracują tak, jak w rozwiązaniach w pełni zaufanych. Jesteśmy jedynie ograniczeni do bieżącego zbioru witryn.

protected override void CreateChildControls()
    {
      base.CreateChildControls();

      Label ListCount = new Label();
      ListCount.Text = 
        String.Format("There are {0} Lists",
        SPContext.Current.Web.Lists.Count);
      Controls.Add(ListCount);
    }

Kolejny przykład, zablokowany w piaskownicy, działa z SPSecurity. Wytnij i wklej następujący kod do składnika Web Part i wdróż go do piaskownicy:

protected override void CreateChildControls()
    {
      base.CreateChildControls();

      SPSecurity.RunWithElevatedPrivileges(
        delegate
        {
          Label ListCount = new Label();
          ListCount.Text =
            String.Format("There are {0} Lists",
            SPContext.Current.Web.Lists.Count);
          Controls.Add(ListCount);
        });
    }

Wyjątku nie otrzymamy aż do momentu, gdy wykonany zostanie kod w procesie piaskownicy. Wyrzucony wyjątek to „Could not load type 'CodeToRunElevated' from assembly 'Microsoft.SharePoint, Version=14.900.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'”. Ten wyjątek nie jest wyjątkiem zabezpieczeń, ale brakującym wyjątkiem typu. Pojawia się on, ponieważ klasa SPSecurity nie jest częścią SharePoint API w trybie piaskownicy. Możecie się zastanawiać, jak to możliwe, że istnieje brakujący typ wyjątku czasu wykonywania, jeśli Visual Studio skompilowało rozwiązanie bez żadnych wyjątków. Visual Studio kompiluje względem pełnej wersji SharePoint API, ale w czasie wykonywania, SharePoint zamienia pełny interfejs API na API w trybie piaskownicy. To względem tego interfejsu API kod zostaje uruchomiony. Visual Studio może pomóc napisać prawidłowy kod poprzez filtrowanie IntelliSense podczas naszego tworzenia rozwiązania w trybie piaskownicy. Na Ilustracji 7 widzimy, że klasa SPSecurity nie pojawia się na liście. Jednak, jeśli wytniemy i wkleimy kod z rozwiązania w pełni zaufanego, może on nie działać w piaskownicy, a Visual Studio nie będzie miało możliwości sprawdzenia tego.

Ilustracja 7 Filtrowanie IntelliSense pomaga tworzyć prawidłowe rozwiązania w trybie piaskownicy

Praca w piaskownicy

Widzieliśmy już, jak należy wdrażać i budować rozwiązania w trybie piaskownicy. Zbadajmy zatem teraz, co możemy robić w piaskownicy.

Rozwiązania w trybie piaskownicy mają dostęp do obszernego podzbioru funkcji w obszarze nazw Microsoft.SharePoint. Zasadniczo wszystkie klasy w SPSite są dostępne. Oznacza to, że dostępne są SPSite, SPWeb, SPList oraz SPListItem. W rozwiązaniu w trybie piaskownicy można tworzyć składniki Web Part, definicje oraz wystąpienia listy, typy oraz pola zawartości oraz odbiorniki zdarzeń. Pełny interfejs API w trybie piaskownicy zostaje udokumentowany w SharePoint SDK.

 Na ogół proces piaskownicy uniemożliwia dostęp do danych poza zbiorem witryn, gdzie wdrożone zostało rozwiązanie. Oznacza to, na przykład, że niemożliwe jest uzyskanie dostępu do Internetu, w celu wywołania usługi sieci Web, do twardego dysku, w celu odczytania, lub zapisania plików, ani do kodu, który nie jest oznaczony, by zezwalać na częściowo zaufanych wywołujących. Niemożliwe jest również wdrożenie plików na dysku, lub dodanie zestawu do pamięci podręcznej GAC w rozwiązaniu w trybie piaskownicy, a zbiór funkcji związany z zabezpieczeniami, taki jak uruchomiony RunWithElevatedPriviledges oraz inne metody SPSecurity, jest niedozwolony.

Możliwe jest natomiast odczytywanie i zapisywanie list i bibliotek wewnątrz tego samego zbioru witryn. Piaskownica zapewnia wystarczający zbiór funkcji, aby utworzyć większość aplikacji wymaganych na poziomie witryny. Czasami jednak, może pojawić się chęć włączenia rozwiązań w trybie piaskownicy, aby wyjść poza piaskownicę, w celu przeprowadzenia zaufanej operacji, takiej jak wywoływanie usługi sieci Web, czy uzyskanie dostępu do bazy danych. Najlepszym sposobem wyjścia poza piaskownicę jest użycie usług Business Connectivity Services (BCS), w celu utworzenia typu zawartości zewnętrznej. Następnie możliwe jest odczytywanie i zapisywanie w źródle danych z rozwiązania w trybie piaskownicy. Innym, bardziej zaawansowanym sposobem wyjścia poza piaskownicę jest utworzenie klasy uruchamianej w całkowicie zaufanym procesie poza procesem roboczym w trybie piaskownicy do połączeń serwera proxy. Niniejsza klasa Proxy wdrażana jest, jako farma i jest możliwa do wywołania z rozwiązania w trybie piaskownicy. Mimo, iż opis tworzenia całkowicie zaufanego proxy wykracza poza zakres niniejszego artykułu, powinniśmy być świadomi jego funkcjonalności.

Monitorowanie rozwiązań

Administratorzy farmy są odpowiedzialni za utrzymanie dobrej kondycji oraz bezpieczeństwa farmy SharePoint. Ponadto posiadają oni obecnie narzędzia monitorowania i ustawiania przydziałów w rozwiązaniach w trybie piaskownicy. SharePoint zapewnia administratorom sieci interfejs użytkownika w administracji centralnej, w celu przypisywania przydziałów zasobów do każdego zbioru witryn. Dostęp do przydziałów możliwy jest przez stronę administracji centralnej w sekcji Zarządzanie aplikacjami. Następnie należy kliknąć Konfiguracja przydziałów i blokowania w sekcji Zbiory witryn. Można również przejść bezpośrednio do strony na /_admin/sitequota.aspx w witrynie administracji centralnej.

Strona Przydziały i blokowanie, pokazana na Ilustracji 8, pozwala wybrać zbiór witryn, na którym chcemy pracować. W sekcji Informacje o przydziale witryny można ustawić właściwości Przydział zasobów rozwiązań użytkownika. Możliwe jest włączenie maksymalnego limitu dziennego i ustawienie liczby dozwolonych punktów. Domyślna wartość to 300 punktów. Punkty liczone są w oparciu o liczbę czynników, do czego dojdę za chwilę. Można również włączyć alert e-mail dla sytuacji, w której osiągnięta zostanie określona ilość punktów ustawiona domyślnie na wartość 100. Strona pokazuje również bieżące użycie dla danego dnia i średnie użycie przez ostatnie 14 dni. Niniejsze dwa elementy zapewniają takie same wartości, jakie administrator zbioru witryn może monitorować w górnej części Galerii rozwiązań.

Ilustracja 8 Administratorzy farm kontrolują przydziały zasobów

Administratorzy farm mogą również dostosowywać przydziały zasobów rozwiązań przy użyciu programu Windows PowerShell. Program ten, na przykład, znaczenie ułatwia przejście przez każdy zbiór witryn i resetuje wartości do wysokości domyślnej. Użycie polecenia Get-SPSite oraz przesłanie go do oświadczenia foreach zmienia wszystkie wartości przy użyciu jednej linijki kodu. Aby ten kod uruchomić, otwórz okno Konsoli zarządzania SharePoint 2010 z menu Start i wpisz następujące polecenia:

Get-SPSite | foreach-object {$_.Quota.UserCodeMaximumLevel = 300}
Get-SPSite | foreach-object {$_.Quota.UserCodeWarningLevel = 100}

Jeśli chcesz sprawdzić wyłącznie bieżące przydziały, możesz uruchomić następujące polecenie PowerShell:

Get-SPSite | foreach-object {$_.Quota}

Niniejsze polecenie wyświetla właściwości przydziałów dla każdego zbioru witryn w farmie. PowerShell formatuje informacje wyjściowe dotyczące właściwości przydziałów dla zbioru witryn, w formie prostej listy, takiej jak:

QuotaID                   : 0
StorageMaximumLevel         : 0
InvitedUserMaximumLevel     : 0
StorageWarningLevel         : 0
UserCodeWarningLevel        : 100
UserCodeMaximumLevel        : 300
UpgradedPersistedProperties :

UserCodeWarningLevel oraz UserCodeMaximumLevel to dwie właściwości przydziału, które sterują rozwiązaniami w trybie piaskownicy. Na niektórych stronach administracyjnych oraz w modelu obiektu SharePoint znajdują się terminy „kod użytkownika” i „rozwiązania użytkownika”, które odnoszą się do kodu i rozwiązań w trybie piaskownicy. Właściwości te pozwalają na dostosowanie liczby punktów przypisanych do każdego zbioru witryn. Można również dostosować algorytm, którego używa się do obliczania wartości punktu. Punkty liczone są na podstawie różnych mierników, które zaprojektowano, aby monitorowały użycie zasobów serwera, w celu dokładnego odzwierciedlenia prawdziwej jego kondycji. SharePoint zawiera 14 mierników, które składają się na punkty przydziału.

  1. AbnormalProcessTerminationCount
  2. CPUExecutionTime
  3. CriticalExceptionCount
  4. InvocationCount
  5. PercentProcessorTime
  6. ProcessCPUCycles
  7. ProcessHandleCount
  8. ProcessIOBytes
  9. ProcessThreadCount
  10. ProcessVirtualBytes
  11. SharePointDatabaseQueryCount
  12. SharePointDatabaseQueryTime
  13. UnhandledExceptionCount
  14. UnresponsiveprocessCount

Każdy miernik o nazwie ResourceMeasure posiada właściwość ResourcesPerPoint. W celu wyliczenia użytych punktów dla tej kategorii, wartość ResourcesPerPoint dzielona jest przez zużyte zasoby. Na przykład, AbnormalProcessTerminationCount ma wartość ResourcesPerPoint równą 1. Za każdym razem, gdy rozwiązanie w trybie piaskownicy nieprawidłowo zakończy działanie, możliwe jest ustawienie innej wartości ResourcesPerPoint na np. 2. Można również użyć wartości 0, jeśli ten miernik nie jest dla nas ważny. Inne mierniki ResourceMeasures mogą nie być zgodne w stosunku jeden do jednego ze zdarzeniem. Miernik CPUExecutionTime uniemożliwia rozwiązaniu w trybie piaskownicy zużycie zbyt wielu cykli CPU. Domyślna wartość ResourcesPerPoint dla CPUExecutionTime to 3600.

Kolejna wartość, AbsoluteLimit, zwiększa się za każdym razem, gdy rozwiązanie otrzymuje punkt. Jeśli rozwiązanie przekroczy wartość AbsoluteLimit, zostaje zakończone nawet, jeśli dzienny limit użycia nie został osiągnięty. Przekroczenie wartości AbsoluteLimit wpływa wyłącznie na pojedyncze rozwiązanie, w przeciwieństwie do dziennego limitu użycia. Wskazane dwa poziomy przydziałów, limit dzienny i limit bezwzględny, współdziałają, by chronić kondycję farmy. Zdecydowanie zalecam, aby nie modyfikować ResourceMeasures , jednak deweloperzy, lub administratorzy powinni wiedzieć, jak te mechanizmy działają.

Mimo, że SharePoint nie zapewnia strony administrowania do przystosowywania mierników przydziałów, możemy zobaczyć i zmieniać wartości przy użyciu modelu obiektu SharePoint, lub programu Windows PowerShell. Następujący skrypt PowerShell umieszcza wszystkie 14 obiektów ResourceMeasure na liście zawierającej wszystkie właściwości dla każdego obiektu ResourceMeasure. Ilustracja 9 pokazuje przykładowe dane wyjściowe z dwóch wartości AbnormalProcessTerminationCount oraz CPUExecutionTime.

[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$spusercodeservice = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$spusercodeservice.ResourceMeasures

Ilustracja 9 Przykładowe dane wyjściowe dla obiektów ResourceMeasure

MinimumThreshold        : 0
ResourcesPerPoint       : 1
AbsoluteLimit               : 1
Name                    : AbnormalProcessTerminationCount
TypeName                : Microsoft.SharePoint.Administration.SPResourceMeasure
DisplayName                 : AbnormalProcessTerminationCount
Id                  : 878646dd-2460-4e88-83cd-67e938fb069c
Status                  : Online
Parent                  : SPUserCodeService Name=SPUserCodeV4
Version                 : 2308
Properties               : {}
Farm                    : SPFarm Name=SharePoint_Config
UpgradedPersistedProperties     : {}

MinimumThreshold        : 0.1
ResourcesPerPoint       : 3600
AbsoluteLimit               : 60
Name                    : CPUExecutionTime
TypeName                : Microsoft.SharePoint.Administration.SPResourceMeasure
DisplayName              : CPUExecutionTime
Id                  : 418cbb0f-d191-4633-9177-7a4568d11d8d
Status                  : Online
Parent                  : SPUserCodeService Name=SPUserCodeV4
Version                 : 2265
Properties              : {}
Farm                    : SPFarm Name=SharePoint_Config
UpgradedPersistedProperties     : {}

Wartości można również dostosować programowo przy użyciu modelu obiektu SharePoint. Można uzyskać odwołanie do usługi piaskownicy z właściwości statycznej o nazwie Lokalny w obiekcie SPUserCodeService i przejść przez zbiór ResourceMeasures. Oto przykład:

SPUserCodeService userCodeService = 
            SPUserCodeService.Local;

      SPResourceMeasureCollection rmc =
        userCodeService.ResourceMeasures;

      foreach (SPResourceMeasure resourceMeasure in rmc)
      {
        Console.WriteLine(resourceMeasure.Name);
      }

Sprawdzanie poprawności rozwiązań w piaskownicy

Struktura piaskownicy SharePoint zapewnia administratorom farm dodatkowy sposób monitorowania i sprawdzania poprawności rozwiązań uruchamianych w piaskownicy. Administratorzy farm mogą wdrożyć moduł sprawdzania poprawności, który uruchamia się, gdy rozwiązanie zostaje przekazane do Galerii rozwiązań. Administratorzy mogą tworzyć moduły sprawdzania poprawności, które np. dopuszczają uruchomienie wyłącznie kodu podpisanego określonym certyfikatem, lub które dopuszczają wyłącznie składniki Web Part. Kolejnym sposobem wykorzystania modułów sprawdzania poprawności jest logowanie oraz katalogowanie rozwiązań w farmie podczas ich aktywacji. Wyraźnie widać, jak to proste, ale skuteczne narzędzie pomaga administratorom farm w obsłudze rozwiązań uruchamianych w farmie.

Podczas aktywacji rozwiązania wywoływany jest każdy moduł sprawdzania poprawności rozwiązań. Jeśli moduł sprawdzania poprawności zostanie uaktualniony, rozwiązania przy kolejnym uruchomieniu są sprawdzane ponownie. Moduł sprawdzania poprawności tworzymy wewnątrz projektu funkcji w farmie SharePoint poprzez dodanie klasy pochodzącej z modułu sprawdzania poprawności SPSolutionValidator. Klasa modułu sprawdzania poprawności musi posiadać przypisany do niej atrybut System.Runtime.InteropServices.Guid. Aby utworzyć wartość GUID możemy użyć narzędzia Utwórz GUID z menu Narzędzia Visual Studio. Wartość ta wykorzystywana jest jako właściwość ProviderID.

Następnie dodajemy konstruktora, który odwołuje się do UserCodeService. Wywołuje on konstruktora klasy podstawowej, przekazując UserCodeService oraz nazwę ciągu modułu sprawdzania poprawności. W konstruktorze do modułu sprawdzania poprawności należy przypisać właściwość „podpis”. Domyślny moduł sprawdzania poprawności dostarczany z systemem Windows używa wartości 1. Tworząc przykład, można użyć 1234. Właściwość podpisu używana jest przez SharePoint, w celu określenia, czy moduł sprawdzania poprawności się zmienił. Dobrze by było, aby w module sprawdzania poprawności produkcji, wartość ta była skrótem zawierającym informacje o wersji modułu sprawdzania poprawności.

Następnie nadpisujemy metody ValidateSolution i ValidateAssembly. Metoda ValidateSolution wywoływana jest jeden raz dla każdego rozwiązania, a ValidateAssembly raz dla każdego zestawu w każdym rozwiązaniu. Do metody ValidateSolution przekazany zostaje obiekt SPSolutionValidationProperties, który zawiera kilka właściwości używanych do sprawdzania poprawności rozwiązań. Najważniejszą właściwością jest właściwość Prawidłowy. Domyślnie, właściwość ta ustawiona jest na wartość Fałsz, więc należy ją ustawić na wartość Prawda, bo inaczej rozwiązanie nie przejdzie pomyślnie przez proces sprawdzania poprawności. Można również ustawić ValidationErrorMessage oraz ValidationErrorUrl, aby przesyłały z powrotem informacje o tym, dlaczego rozwiązanie nie przeszło pomyślnie procesu sprawdzania poprawności. Ponadto możliwe jest użycie kolekcji Pliki w celu uzyskania odwołania do wszystkich plików w pakiecie rozwiązania. Do wystąpienia ValidateAssembly przekazane zostaje odwołanie do SPSolutionValidatorProperties, jako dodatek do SPSolutionFile, czyli odwołanie do zestawu w pakiecie rozwiązania. Ilustracja 10 pokazuje przykład moduł sprawdzania poprawności rozwiązań.

Ilustracja 10 Moduł sprawdzania poprawności rozwiązań

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.UserCode;

namespace SandboxSolutionValidator
{
  [Guid("DAC77CB7-7511-4E7E-8427-B6A57C5F49F7")]
    class SandboxSolutionValidator:SPSolutionValidator
    {
    [Persisted]
    List<string> PutSomeStringsHere;

    private const string validatorName = "Sandboxed solution Validator";

    public SandboxSolutionValidator(
      SPUserCodeService userCodeService) :
      base(validatorName, userCodeService)
    {
      this.Signature = 1234;
    }

    public override void ValidateSolution(
      SPSolutionValidationProperties properties)
    {
      //System.Diagnostics.Debugger.Launch();
      base.ValidateSolution(properties);
       
      //Determine whether the solution is valid
      properties.Valid = true;

      //Iterate over each file in the solution
      foreach (SPSolutionFile file in 
                properties.Files) { }

      //Set the error message and Url if it’s not valid
      properties.ValidationErrorMessage =
        "The solution is not valid";
      properties.ValidationErrorUrl =
        "http://moss.Contoso.com/MyErrorPage.apx";
    }

    public override void ValidateAssembly(
      SPSolutionValidationProperties properties, 
      SPSolutionFile assembly)
    {
      //System.Diagnostics.Debugger.Launch();
      base.ValidateAssembly(properties, assembly);

      properties.Valid = true;
    }
    }
}

Moduł sprawdzania poprawności rozwiązań należy dodać do zbioru SPUserCodeService SolutionValidators. Można to zrobić przy użyciu programu Windows PowerShell, jednak zalecany sposób polega na wdrożeniu modułu sprawdzania poprawności przy użyciu funkcji na poziomie farmy. W funkcji, aby dodać moduł sprawdzania poprawności do zbioru, należy użyć odbiornika funkcji. W zdarzeniu FeatureActivated (patrz Ilustracja 11) otrzymamy odwołanie do SPUserCodeService farmy. SPUserCodeService wykorzystywane jest do tworzenia wystąpienia modułu sprawdzania poprawności, a następnie dodania tego wystąpienia do zbioru SolutionValidators w UserCodeService. Niniejsze operacje mogą być dość trudne do debugowania, ale wystarczy do kodu dodać polecenia Debugger.Launch. Działanie to rozpoczyna wystąpienie Visual Studio i załącza kod do odpowiedniego procesu. Należy upewnić się, że wskazane polecenia zostaną usunięte po zakończeniu opracowywania modułu sprawdzania poprawności.

Ilustracja 11 Wdrażanie modułu sprawdzania poprawności

public override void FeatureActivated(
        SPFeatureReceiverProperties properties)
    {
      //System.Diagnostics.Debugger.Launch();

      SPUserCodeService userCodeService =
            SPUserCodeService.Local;

      SPSolutionValidator validator = new SandboxSolutionValidator(userCodeService);

      userCodeService.SolutionValidators.Add(
            validator);
    }

Programu PowerShell można użyć do wyświetlenia listy modułów sprawdzania poprawności zainstalowanych w farmie, co pozwala administratorom szybko zweryfikować, które moduły sprawdzania poprawności zostały zainstalowane. Techniczna wersja demonstracyjna programu SharePoint 2010 dostarczana jest z domyślnym modułem sprawdzania poprawności rozwiązania. Moduł ten wyłącznie ustawia prawidłową właściwość na wartość Prawda. Aby wyświetlić listę zainstalowanych modułów sprawdzania poprawności, wprowadź następujący skrypt programu PowerShell. Ilustracja 12 pokazuje wynik tego działania**.**

[System.Reflection.Assembly]::Load(
"Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
$spusercodeservice = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local;
$spusercodeservice.solutionvalidators;

Ilustracja 12 Zainstalowane moduły sprawdzania poprawności rozwiązań

Przyjrzeliśmy się, jak należy tworzyć, wdrażać oraz sprawdzać kod w trybie piaskownicy w danej farmie. Niniejszy przykład powinien umożliwić utworzenie wydajnego i ciekawego kodu walidacji, który zapewni farmie niezwykłą elastyczność oraz zabezpieczenia.

Tryb piaskownicy jest domyślny

Jak wspomniano wcześniej, domyślny typ projektu SharePoint w Visual Studio jest rozwiązaniem w trybie piaskownicy. Takie domyślne ustawienie powinno na stałe zagościć w naszym postrzeganiu tej kwestii. Powinniśmy mieć na uwadze tworzenie rozwiązań SharePoint tak, aby uruchamiane były w środowisku piaskownicy. Przekonaliśmy się, że aplikacje w trybie piaskownicy są bardzo sprawne, mogą wykonywać większość zadań, jakich firma potrzebuje i, kiedy będzie to konieczne, zapewnić możliwość przerwania ich w bezpieczny sposób. Rzeczywistą korzyścią jest prędkość, z jaką możliwe jest wdrażanie rozwiązań w przedsiębiorstwie. Nie ma już potrzeby przeprowadzania wyczerpujących procesów testowania i walidacji każdego utworzonego rozwiązania. Należy jednak pamiętać o stosowaniu dobrych praktyk dotyczących oprogramowania. Administratorzy zbioru witryn będą mieli możliwość sterowania własnymi zbiorami i uruchamiania odpowiednich rozwiązań dla swoich witryn. Administratorzy farm zostaną zwolnieni z obowiązku wykonywania zadań kontrolowania i zarządzania wszystkimi żądaniami instalacji rozwiązań i będą mogli skoncentrować się na ogólnej kondycji farmy dzięki rozbudowanym narzędziom monitorującym.

Na zakończenie, przewiduję, że będziemy świadkami rozkwitu rozwiązań SharePoint. Pojawi się zwiększona liczba napisanych i wdrażanych rozwiązań dla przedsiębiorstw oraz ogromny rozwój społeczności SharePoint, ponieważ rozwiązania będą bardziej dostępne i łatwo je będzie znaleźć, zainstalować i uruchomić.