ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Синхронизация профилей пользователей MS SharePoint Portal Server 2003 с внешним источником данных

Profile sinchronization of MS SharePoint Portal Server 2003 users with external data source
Статья опубликована в выпуске журнала № 3 за 2012 год. [ на стр. 135-137 ][ 12.09.2012 ]
Аннотация:При построении корпоративных порталов одной из важных задач является синхронизация данных, публикуемых на портале, с данными, используемыми другими приложениями и хранимыми в различных форматах средствами различных СУБД. В случае, когда данные на портале могут редактироваться пользователями или сторонними при-ложениями, необходимо организовать их синхронизацию. Когда один из источников данных назначается главным, а другой подчиненным, синхронизация не представляет трудностей. В том случае, когда может потребоваться двуна-правленность, необходимо обеспечить как прямую, так и обратную синхронизацию. В статье рассматриваются решение задачи синхронизации профилей пользователей MS SharePoint Portal Server 2003 (SPS) с внешним источником данных – унаследованной подсистемой отдела кадров и обратная синхронизация этого источника с данными профилей пользователей SPS. Рассмотрены два варианта получения данных из пользовательских профилей: с помощью SQL-запроса и с применением объектной модели SPS. Для организации синхронизации предлагается использовать промежуточный файл в формате XML. Такое решение позволяет заменить источник синхронизируемых данных без существенных изменений в уже имеющемся программном обеспечении. Кроме того, он предоставляет возможность передать данные третьей стороне или получить их от нее. Приводятся примеры скриптов на языке сценариев PowerShell, входящем в стандартную поставку MS Windows, реализующие прямую и обратную синхронизацию. Кроме задачи синхронизации, рассмотренный подход может использоваться для переноса данных при переходе с MS SharePoint на другую платформу.
Abstract:In the process of development of enterprise portals one of most important problems is data synchronization published in such portal with data used by other applications and stored in different formats in DBMS. When the data placed in portal can be edited by a user or other application, they should be synchronized. When one of the data sources assigned as the master source and the other one is assigned as a slave source it is not difficult to arrange synchronization. When bidirectional structure is needed, it shall be necessary to provide «direct» and «reverse» synchronization. The article discusses synchronization solution of MS SharePoint Portal Server 2003 (SPS) users with a data source – inherited personnel department subsystem and «reverse» synchronization of this external source with profile data of SPS users. The article presents two ways of data collection from user profiles: with SQL query and use of object SPS model. Synchronization is made with temporary XML file. Such solution changes source of synchronized data without significant change in existing software. In addition, it provides opportunity to the third party to transfer or receive the data from it. The article contains some scripts written in PowerShell scenario language included in standard MS Windows package with implementation of «direct» and «reverse» synchronization. Beside synchronization, this approach can be used for the data transfer in case of changing MS SharePoint platform to a different one.
Авторы: Ермаков Д.Г. (Ermak@imm.uran.ru) - Институт математики и механики УрО РАН, г. Екатеринбург, г. Екатеринбург, Россия
Ключевые слова: sql., ms sharepoint portal server 2003 (sps), ms windows powershell, профиль пользователя, обратная синхронизация, синхронизация, экспорт данных, импорт данных
Keywords: SQL, MS SharePoint Portal Server 2003 (SPS), SQL, ms windows powershell, user profile, reverse synchronization, synchronization, back synchronization, synchronization
Количество просмотров: 6154
Версия для печати
Выпуск в формате PDF (7.64Мб)
Скачать обложку в формате PDF (1.33Мб)

Размер шрифта:       Шрифт:

Одна из важных функций корпоративного портала – публикация информации о сотрудниках предприятия. В случае использования 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).


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=3229
Версия для печати
Выпуск в формате PDF (7.64Мб)
Скачать обложку в формате PDF (1.33Мб)
Статья опубликована в выпуске журнала № 3 за 2012 год. [ на стр. 135-137 ]

Возможно, Вас заинтересуют следующие статьи схожих тематик: