Software & Systems

Одна из важных функций корпоративного портала – публикация информации о сотрудниках предприятия. В случае использования MS SharePoint Portal Server 2003 (SPS) хранилищем данных о сотрудниках служат профили пользователей (Users Profiles). Стандартно информация о сотрудниках может заноситься в профили пользователей вручную самим пользователем или системным администратором, а также автоматически синхронизироваться с данными Active Directory (AD). Перечень атрибутов профиля, их соответствие полям AD и возможность редактирования самим пользователем устанавливаются администратором SPS. На практике данные для заполнения профилей могут находиться во внешних по отношению к AD и SPS хранилищах, например, в унаследованной кадровой системе на основе СУБД MySQL, выполняющейся под управлением некоторой версии ОС Linux. Для таких источников данных требуется создание специального программного модуля, соответствующего категории ETL (Extract-Transformation-Load) [1] и обеспечивающего

–      извлечение данных (data extraction) из их источника;

–      изменение структуры, формата и/или типов данных (data transformation) для их соответствия номенклатуре полей профилей пользователей SharePoint;

–      их последующую загрузку (data load) в профили.

В качестве инструмента для создания такого модуля используется свободно распространяемый язык сценариев MS Windows PowerShell [2]. PowerShell разработан на платформе MS .NET Framework, благодаря чему в сценариях на основе этого языка можно манипулировать объектами любых .NET-приложений, одним из которых является MS SharePoint [3]. В своем составе он также имеет мощные средства для работы с данными в XML-формате.

Для получения доступа к информации в профилях пользователей в PowerShell-скрипте следует обратиться к объектной модели SharePoint [3]. Для этого скрипт должен выполняться с правами администратора на том же сервере, что и целевой сервер SharePoint. Процедура загрузки данных может быть разделена на два независимых шага и, соответственно, на два сценария PowerShell. На первом шаге данные извлекаются из внешнего хранилища и сохраняются в универсальном промежуточном формате. В качестве такого промежуточного формата данных выберем формат XML-разметки, соответствующий структуре данных профиля пользователя SharePoint. Благодаря такому подходу остальные действия уже не зависят от конкретного источника данных. Кроме того, эти XML-данные могут использоваться и для других задач. Скрипт для создания такого XML-документа зависит от конкретного источника данных и здесь рассматриваться не будет.

На втором шаге PowerShell-скрипт считывает эти XML-данные и записывает в профили пользователей. Рассмотрим подробнее действия, выполняемые скриптом на втором шаге.

Сначала для получения доступа к свойствам и методам SPS необходимо подключить его библиотеки. В PowerShell это делается следующими предложениями:

[System.Reflection.Assembly]::LoadWithPartialNa­me("Microsoft.SharePoint") | Out-Null

[System.Reflection.Assembly]::Load("Microsoft.Share­Point.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | Out-Null

Далее получаем коллекцию профилей пользователей портала. Для этого понадобится объект типа system.URI, обязательно содержащий полный URL-адрес целевого портала. В примерах кода для данного объекта будем использовать имя $uri.

Создаем объект TopologyManager:

$TopologyManager = new-object Microsoft.SharePoint. Portal.Topology.TopologyManager

(заметим, что этот объект доступен только пользователю с правами администратора).

Окончательно выделяем коллекцию профилей SPS:

$PortalSite = $TopologyManager.PortalSites[$uri]

$PortalContext = [Microsoft.SharePoint.Portal.Portal- Application]::GetContext($PortalSite)

$UserProfileManager = New-Object Microsoft.Share­Point.Portal.UserProfiles.UserProfileManager($PortalContext)

Заранее подготовленные для синхронизации данные загружаем из файла в XML-объект PowerShell и проходим в цикле по всем атрибутам этого объекта.

Если профиль для данной учетной записи существует, сравниваем поля, которые требуется обновлять, и, если есть различия, вносим изменения.

MS SharePoint Portal Server 2003 (MS SPS) предоставляет возможность каждому неанонимному пользователю редактировать данные своего профиля, в том числе и в тех полях, которые загружаются из некоторого внешнего источника данных.

Будем считать, что данные, введенные пользователем, наиболее актуальны. Пусть пользователь имеет право редактировать значения автоматически заполняемых атрибутов своего профиля. Тогда, если не принять специальные меры, после очередного автоматического обновления изменения, сделанные пользователем, будут утрачены. Поэтому для применения изменений, внесенных пользователем в свой профиль, к данным в хранилище-первоисточнике требуется разработать специальный программный модуль. Процедуру, реализуемую таким модулем, назовем процедурой обратной синхронизации. Она относится к системам категории ETL (Extract-Transformation-Load) [1], которые предусматривают извлечение данных (data extraction) из источника, изменение структуры и/или формата данных (data transformation) для их использования в целевом приложении и отправки этому приложению (data load) [2]. В рассматриваемом случае выполняется обращение к БД профилей SPS, из которой извлекаются значения атрибутов профилей, сопоставленных пользователям. Далее данные, извлеченные из профилей, сравниваются с соответствующими данными в исходном хранилище, и в случае обнаружения различий в исходном хранилище происходит обновление.

В качестве инструмента для создания такого модуля используем MS PowerShell.

Рассмотрим два варианта получения доступа к данным профилей пользователей.

В первом варианте используем объектную модель SharePoint [3]. Скрипт должен выполняться с правами администратора на том же сервере, что и SPS.

Как и в случае прямой синхронизации, для доступа к свойствам и методам объектной модели SPS подключаем соответствующие библиотеки и создаем объект, содержащий профили пользователей. В цикле проходим по всем профилям, на основе значения их атрибутов формируем соответствующий XML-документ и сохраняем его в файл.

Второй вариант основывается на SQL-запросе к данным, хранимым во внутреннем представлении БД, лежащей в основе SPS [4]. Однако такой запрос нельзя построить сразу. Чтобы его сформировать, необходимо установить соответствие между номерами и именами атрибутов профилей пользователей. Для этого используем следующий прием:

–      создаем специальную пользовательскую учетную запись и соответствующий этой записи профиль пользователя;

–      заполняем профиль таким образом, чтобы по значению атрибутов можно было восстановить их имена;

–      выполняем следующее предложение SQL для получения списка всех номеров атрибутов пользовательского профиля:

SELECT DISTINCT propertyid FROM userProfile- Value upv

INNER JOIN userProfile up on upv.recordid=up.re- cordid;

–      для каждого номера атрибута из полученного списка выполняем запрос, извлекающий содержимое этого атрибута (номер атрибута передается в запрос как значение переменной $tst):

SELECT ntName, MAX(Test) AS Test

FROM (

SELECT ntName, propertyVal,

(CASE WHEN propertyid = $tst THEN propertyVal

ELSE '' END) AS Test

FROM userProfileValue upv INNER JOIN

userProfile up on upv.recordid=up.re- cordid

WHERE propertyid in ($tst)

) AS tbl GROUP BY ntName ORDER BY ntName;

–      на основе значений атрибутов восстанавливаем соответствие номеров атрибутов их именам; теперь можно сформировать требуемое SQL-пред­ложение. В сокращенном варианте оно будет иметь вид

SELECT ntName,

max(AccountName) AS AccountName,

max(FirstName) AS FirstName,

max(LastName) AS LastName,

max(PreferredName) AS PreferredName

FROM (

SELECT ntName, propertyVal,

(case when propertyid = 3 then propertyVal else '' end) AS AccountName,

(case when propertyid = 4 then propertyVal else '' end) AS FirstName,

(case when propertyid = 5 then propertyVal else '' end) AS LastName,

(case when propertyid = 7 then propertyVal else '' end) AS PreferredName

FROM userProfileValue upv INNER JOIN userProfile up on upv.recordid=up.recordid

WHERE propertyid IN (3, 4, 5, 7)

) AS SPSuserProfile GROUP BY ntName ORDER BY ntName

FOR XML AUTO, ELEMENTS, ROOT('SPSProfiles');

В результате выполнения скрипта получается файл в формате XML, содержащий данные из профилей пользователей. Далее этот файл может быть передан для загрузки данных в некоторое внешнее хранилище (например, в AD или кадровую БД). Следует отметить, что подобный скрипт может выполняться не только на том же сервере, что и SPS, если удаленный доступ к БД профилей разрешен политиками безопасности.

После того, как все сценарии синхронизации готовы, для их автоматического запуска необходимо настроить планировщик заданий Windows. Следует обратить внимание на то, что при планировании операций прямой и обратной синхронизации данных обратная синхронизация должна выполняться ранее прямой.

Рассмотренный подход может использоваться не только в задаче синхронизации, но и для переноса данных при миграции с MS SharePoint на другую платформу.

Литература

1.     Дубова Н. Краткий курс интеграции данных // Открытые системы. 2007. № 9.

2.     Попов А.В. Введение в Windows PowerShell. СПб: БХВ-Петербург, 2009. 464 с.

3.     MSDN: SharePoint Products and Technologies 2003. URL: http://msdn.microsoft.com/en-us/library/bb931735(v=offi­ce.12).aspx (дата обращения: 27.04.2010).

4.     Bill English. SharePoint User Profiles Write Back to Active Directory. URL: http://mindsharpblogs.com/bill/archive/2005/ 08/30/681.aspx (дата обращения: 30.08.2005).