Управление корпоративными проектами с помощью SharePoint

Какие технологии SharePoint подходят для меня? В своих усилиях найти ответ средний читатель, вероятно, продирался через кажущийся бесконечным список категорий, таких как сотрудничество и социальные сети, порталы, корпоративный поиск, управление корпоративным информационным содержимым, бизнес-процессы и формы, бизнес-аналитика, наконец, возможности платформ разработки, и сравнивал функции, доступные в Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007 и Microsoft Office SharePoint Server (MOSS) 2007. Однако существует одна технология, которую он вряд ли рассматривал, поскольку корпорация Майкрософт не включает ее в список продуктов и технологий SharePoint – технология управления корпоративными проектами (Enterprise Project Management – EPM), реализуемая через Microsoft Office Project Server (MOPS) 2007.

Но MOPS 2007 является технологией SharePoint; она построена на основании и расширяет WSS 3.0 способом, который сравним с MOSS 2007. MOPS 2007 – правильный выбор для тех, кому нужно повысить экономичность сотрудничества внутри отделов и между ними посредством управления работой, ресурсами и бюджетом, выходящего за пределы ограниченных возможностей управления задачами, входящих в WSS 3.0 и MOSS 2007. С помощью MOPS можно превращать веб-узлы групп в рабочие области проектов, управлять сотрудничеством групп внутри отделов и за их пределами и создавать основательный фундамент EPM для всей организации. Но в первую очередь необходимо преодолеть проблемы развертывания.

В этой статье я рассказываю о развертывании MOPS 2007 в среде Windows Server 2008 с SQL Server 2005 с пакетом обновления 2 (SP2) и WSS 3.0 с пакетом обновления 1 (SP1). Сперва я кратко освещаю архитектуру MOPS, чтобы показать, как компоненты интегрируются с WSS 3.0 с точки зрения системного архитектора. Эта информация упрощает понимание последующего рассказа об обычных проблемах развертывания и интеграции, с которыми можно столкнуться, такими как проблемы настройки пула приложений, отсутствующие права на доступ, ошибки запуска системы очереди и проблемы, относящиеся к службам аналитики SQL Server 2005.

Чтобы проиллюстрировать действия по развертыванию и устранению неполадок, я использую базовую тестовую среду с двумя серверами WSS 3.0 в ферме серверов, выделенным контроллером домена и отдельным компьютером для SQL Server, подобную тестовой среде, которую я использовал ранее для статей в этой рубрике о SharePoint. Соответствующие таблицы с поэтапными указаниями можно найти в сопровождающем материале к этой статье, расположенном на веб-узле журнала TechNet Magazine.

Архитектура Project Server

MOPS 2007 – одно из наиболее передовых и сложных приложений SharePoint. Оно в полной мере использует преимущества платформы WSS 3.0 для централизованного администрирования, предоставления веб-узлов, проверки подлинности и безопасности. Кроме того, в нем добавлены дополнительные компоненты, такие как 25 основных и специализированных веб-компонентов MOPS и новая коллекция, в которой может быть вплоть до четырех баз данных MOPS на веб-узел Project Web Access (PWA). Доступ к каждому из них производится через набор из 21 общедоступной и внутренней веб-службы MOPS, которые вместе формируют интерфейс Project Server Interface (PSI), как показано на рис. 1. Дополнительные сведения о веб-службах MOPS можно найти на MSDN.

Рис. 1. Интеграция SharePoint с MOPS 2007

Архитектура MOPS 2007 полагается на ряд компонентов, распределенных между клиентскими рабочими станциями, серверами приложений и серверами баз данных. О наиболее важных из этих компонентов я рассказываю в данной статье, но те, кого интересуют все технические детали, могут прочесть документацию "Project Server Architecture" в Project 2007 SDK.

Просто при чтении документации комплекта SDK помните, что веб-компоненты PWA и Microsoft Office Project Professional 2007 не производят доступа к веб-службам PSI напрямую. В комплекте SDK предполагается, что клиенты производят прямые вызовы к PSI, но большинство приложений реально используют сервер пересылки PSI, являющийся компонентом веб-узлов PWA и предоставляющий непрямой доступ к веб-службам PSI. Только серверные компоненты, такие как служба очередей и служба событий, работающие с полномочиями уровня системы, выполняют прямые вызовы PSI. Эту небольшую деталь важно помнить в ситуациях устранения неполадок по ряду причин, а именно:

• Веб-узлы PWA определяют контекст баз данных (у каждого веб-узла PWA имеются отдельные базы данных черновиков, публикаций, архива и отчетов) и полномочия пользователей, но обычным учетным записям пользователей не дается доступ к веб-службам PSI.
• Сервер пересылки PSI не поддерживает олицетворение и использует учетную запись пула приложений веб-узла PWA для доступа к веб-службам PSI от имени пользователей.
• Вызовы PSI не обязательно используют локальные веб-службы PSI, если на ферме имеется несколько экземпляров связки приложение-сервер.

Интеграция SharePoint

Теперь давайте взглянем поближе на собственно интеграцию MOPS с SharePoint. С точки зрения администратора SharePoint, MOPS – это общее веб-приложение, управляемое как служба фермы в центре администрирования SharePoint 3.0. Это относительно простая задача для администраторов, знакомых с поставщиками совместно используемых служб (SSP) в MOSS 2007.

Но администратору WSS 3.0, не знакомому с администрированием SSP, следует заглянуть в таблицу «Deploying Project Server 2007» («Развертывание Project Server 2007») в сопровождающем материале для ознакомления с поэтапными указаниями по созданию и настройке общих служб фермы SharePoint и веб-узлов PWA. Вслед за установкой и настройкой MOPS можно проанализировать реализацию системы в IIS Manager. Как показано на рис. 2, на сервере приложений MOPS можно увидеть отдельные веб-узлы для общих служб, администрирования SSP и коллекций веб-узлов.

Рис. 2. Доступ к Project Server 2007 через PWA и сервер пересылки PSI

Клиенты получают доступ к веб-службам PSI через виртуальный каталог _vti_bin/PSI на веб-узле PWA. Однако веб-службы PSI не находятся в виртуальном каталоге. Виртуальный каталог _vti_bin/PSI соответствует следующему физическому пути: %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. Можно будет обнаружить, что этот каталог содержит файл web.config, указывающий в разделе <httpHandlers>, что все запросы HTTP к файлам *.asmx (то есть к основанным на ASP.NET веб-службам) должны быть переданы специальному обработчику HTTP, экземпляр которого создается через Microsoft.Office.Project.Server.PSIForwarderHandlerFactory.

Этим специально созданным обработчиком HTTP является сервер пересылки PSI. Сервер пересылки PSI создает новое подключение HTTP к собственно веб-службам PSI, перенаправляет запрос HTTP клиента и затем возвращает результаты клиенту.

Веб-службы PSI доступны серверу пересылки PSI посредством HTTP через виртуальный каталог PSI веб-приложения общих служб, которое размещено на узле веб-служб Office Server. Этот виртуальный каталог соответствует по умолчанию физическому пути %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI, на котором можно найти файлы MOPS 2007 *.asmx.

Ниже я расскажу о веб-службах Office Server подробнее, пока же наиболее важным фактом, который можно вынести с рис. 2, является то, что сервер перенаправления PSI связывается с веб-службами PSI, используя удостоверение учетной записи пула веб-приложений узла PWA, а не пользователя, производящего доступ к веб-узлу PWA в настоящий момент.

Развертывание фермы серверов

Сервер перенаправления PSI также играет важную роль в развертываниях ферм серверов, в которых для повышения масштабируемости и доступности приложений используются отдельные серверы веб-интерфейса и приложений. Сервер веб-интерфейса MOPS — это сервер WSS 3.0, не размещающий веб-службы PSI или другие службы MOPS (такие, как службы очереди или событий), но представляющий клиентам доступ к веб-узлам PWA, включая сервер перенаправления PSI, как показано на рис. 3.

Рис. 3. Ферма серверов MOPS 2007 среднего размера

Сервер приложений, с другой стороны, является сервером WSS 3.0, на котором установлен полный набор компонентов и служб MOPS. Серверы приложений могут размещать веб-узлы PWA, но чаще всего они лишь предоставляют серверные услуги серверам интерфейса пользователя и не несут службу веб-приложений WSS. Роль сервера можно выбрать в ходе установки MOPS.

На рис. 3 показана настройка фермы серверов среднего размера. К ней можно добавлять новые серверы переднего плана, чтобы повысить масштабируемость, а также дополнительные серверы приложений для высокой доступности в зависимости от требований организации. Настраивать кластер балансировки нагрузки для работы с серверами приложений MOPS не обязательно, поскольку сервер перенаправления PSI автоматически проводит балансировку нагрузки запросов PSI, в случае наличия в ферме нескольких серверов приложений MOPS. Подробную информацию в отношении параметров развертывания MOPS можно найти в документе "Deployment Guide for Office Project Server 2007" («Руководство по развертыванию для Office Project Server 2007»).

Добро пожаловать в IIS 7

Достаточно теории! Давайте перейдем к реальным вопросам, которые могут встать при развертывании MOPS 2007. Один из моих наиболее любимых вопросов относится к назначенным главными коллекциям веб-узлов для узлов PWA. В этом случае пользователь успешно разворачивает MOPS, настраивает SSP, предоставляет узел PWA в режиме заголовка узла путем ввода полного URL-адреса PWA (например, pwa) после выбора пути использования Project Web Access как флажка заголовка узла на странице создания веб-узла Project Web Access. Затем после того, как все ресурсы успешно предоставлены, производится попытка открыть веб-узел, но вместо PWA пользователь выходит на стандартный экран приветствия IIS 7.

Это происходит, когда веб-узел по умолчанию не является расширенным с помощью SharePoint, а другого веб-узла с подходящей привязкой узла для URL-адреса PWA не существует. Без прямой привязки узла IIS связывает запрос pwa с нерасширенным веб-узлом по умолчанию, что позволяет увидеть экран приветствия. Можно было бы ожидать, что центр администрирования SharePoint 3.0 добавит требуемую привязку к веб-приложению SharePoint, выбранному для размещения веб-узла PWA, но этого не происходит.

Чтобы решить эту проблему, необходимо расширить веб-узел по умолчанию с помощью SharePoint и затем использовать эту коллекцию веб-узлов для предоставления веб-узлов PWA, как показано в таблице устранения неполадок IIS и PWA в сопровождающем материале. Как вариант, можно добавить привязку отсутствующего веб-узла вручную в IIS Manager к веб-приложению, выбранному для PWA. Не забудьте выполнить это действие на всех серверах WSS, размещающих веб-узел PWA.

Полномочия базы данных сеанса

Если решено расширить веб-узел по умолчанию, убедитесь, что для пула приложений используется учетная запись домена — см "Plan for Administrative and Service Accounts (Office SharePoint Server)" («Планирование для административных и служебных учетных записей (Office SharePoint Server)») — в противном случае придется столкнуться с касающимися решений проблемами после предоставления веб-узлов PWA, которые, как правило, проявляют себя в обычно неинформативном сообщении об ошибках SharePoint, подобном изображенному на рис. 4.

Рис. 4. Ошибка при доступе к базе данных SSP

Чтобы найти более осмысленную информацию, следует проверить журналы трассировки, расположенные в каталоге %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS. Это может быть долгой и нудной задачей, если в ферме есть несколько серверов интерфейса пользователя со сбалансированной нагрузкой.

В целях поиска и устранения неполадок лучше изменить запись DNS для имени узла PWA так, чтобы она временно указывала на единственный сервер интерфейса пользователей. Этим способом можно узнать, какой сервер обрабатывает клиентские запросы, так что необходимо будет лишь проверить файлы журнала трассировки этого одного сервера.

Откройте последний файл журнала в блокноте и найдите запись "Cannot open database." Если она там есть, то ясно, что существует проблема с полномочиями для базы данных. Например, в журнале трассировки на рис. 4 показано, что у учетной записи LITWARE\WSS02$ нет доступа к базе данных SharedServices1_DB. Это ясно говорит, что веб-узел PWA работает с удостоверением сетевой службы.

LITWARE\WSS02$ — учетная запись компьютера веб-сервера интерфейса пользователей, а SharedServices1_DB — база данных поставщика общих служб. Среди прочего, серверы веб-интерфейса используют данные состояния сеанса ASP.NET в таблице ASPStateTempSessions, но у LITWARE\WSS02$ нет доступа к этой базе данных.

Важно отметить необходимость включить базу данных поставщика общих служб в еженедельные действия по обслуживанию баз данных, чтобы гарантировать стабильную работу системы. Например, следует удалить просроченные данные о состоянии сеанса из ASPStateTempSessions путем использования команды SQL TRUNCATE TABLE ASPStateTempSessions, как задокументировано в "Deploy Project Server 2007 to a Server Farm Environment" («Развертывание Project Server 2007 в среде фермы серверов»).

Проблемы настройки, связанные с Network Service (сетевой службой), могут быть запутанными, так что я рассмотрю их подробнее. Учетные записи доменов (такие как LITWARE\SspConfigAdmin) работают для пулов приложений в фермах серверов, поскольку они идентичны на всех компьютерах. Напротив, учетная запись сетевой службы (NT AUTHORITY\NETWORK SERVICE) различается на всех компьютерах. На сервере интерфейса пользователей, именуемом wss02.litware.com, учетная запись NT AUTHORITY\NETWORK SERVICE преобразуется в LITWARE\WSS02$. Но на сервере sql01.litware.com учетная запись NT AUTHORITY\NETWORK SERVICE преобразуется в LITWARE\SQL01$. В этом и заключается проблема.

Если изучить полномочия SQL Server для SharedServices1_DB в SQL Server Management Studio, можно увидеть, что учетная запись NT AUTHORITY\NETWORK SERVICE имеет полномочия db_owner в попытке дать пулам приложений, использующим учетную запись сетевой службы, доступ к базе данных поставщика общих служб. Но помните, что это работает только в установке с одним сервером.

Все назначения полномочий можно исправить, прямо дав LITWARE\WSS02$ и всем другим учетным записям серверов WSS (возможно LITWARE\WSS01$ и так далее) полномочия db_owner для SharedServices1_DB, но лучше вместо этого использовать учетные записи доменов для пулов приложений, чтобы все серверы интерфейса пользователей использовали то же удостоверение, которому SharePoint дала требуемые полномочия для базы данных.

Полномочия общих служб

Если по любой причине пул приложений веб-узла PWA использует учетную запись сетевой службы, то можно будет также столкнуться с проблемами полномочий, относящимися к SSP. Помните, как я упомянул, что сервер перенаправления PSI получает доступ к веб-службам PSI от имени пользователя в контексте учетной записи пула приложений веб-узлов PWA? Если у этой учетной записи нет полномочий на доступ к узлу веб-служб Office Server, то все идет насмарку с обычным сообщением об ошибке SharePoint. В этот раз в журнале трассировки на сервере переднего плана констатируется "The request failed with HTTP status 401: Unauthorized", как показано на рис. 5.

Рис. 5. The request failed with HTTP status 401: Unauthorized

Помните, что эта ошибка не относится к полномочиям пользователей в PWA. Полномочия SharePoint, предоставленные на веб-узле PWA, определяют, какие пользователи могут получить доступ к виртуальному подкаталогу _vti_bin/PSI этого узла, но эти пользователи не получают полномочий на доступ к веб-приложению общих служб или веб-службам PSI на сервере приложений.

Даже для администратора коллекции веб-узла PWA сервер MOPS выдает сбой, если у учетной записи пула приложений веб-узла PWA нет доступа к веб-службам PSI. Это в особенности верно, если проигнорировать совет использовать учетные записи доменов для пулов приложений в ферме серверов и использовать вместо этого учетную запись сетевой службы.

Чтобы проверить полномочия на доступ SSP на сервере приложений, проверьте файл web.config file в корневом каталоге узла веб-служб Office Server (по умолчанию, %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root). Можно заметить запись NT AUTHORITY\NETWORK SERVICE в разделе <authorization>, которая предположительно должна авторизовывать пулы приложений, использующих учетную запись сетевой службы. Но опять же, это не решение задачи, поскольку учетная запись ссылается только на локальный компьютер, который не является сервером интерфейса пользователя.

Лучшей стратегией является изменение настройки пула приложений и использование учетной записи домена. Но если предполагается использовать учетную запись сетевой службы, то необходимо прямо авторизовать сервер интерфейса пользователя.

Не изменяйте файл web.config на сервере приложений напрямую – SharePoint перепишет такие изменения. Вместо этого используйте центр администрирования SharePoint 3.0, чтобы дать отсутствующие полномочия, как подчеркнуто в таблице "Testing Shared Service Provider Access Permissions" («Тестирование полномочий на доступ для поставщика общих служб»). Кроме того, проверьте настройку при помощи простого приложения ASP.NET, устанавливающего прямое подключение HTTP к веб-службам PSI, такого как SSPCheck (входящего в сопровождающий материал). Для получения надежных результатов просто убедитесь, что приложение ASP.NET работает под управлением пула приложений веб-узла PWA.

Брандмауэр Windows

На этом этапе, скорее всего, возможно открыть PWA, если, конечно, попытка доступа к PWA производится через веб-сервер интерфейса пользователей, и брандмауэр Windows на сервере приложений MOPS блокирует порты TCP 56737 и 56738. Это порты по умолчанию, выделенные веб-службам Office Server для связи HTTP и HTTPS.

SharePoint не открывает эти порты автоматически на сервере приложений MOPS при создании узла веб-служб Office Server. При наличии включенного брандмауэра Windows на сервере приложений необходимо вручную создать правило брандмауэра, чтобы сделать возможным трафик к этим портам, так чтобы серверы переднего плана могли бы получить доступ к веб-службам PSI. Если брандмауэр блокирует эти порты, то будет получено сообщение об ошибке, отображенное на рис. 6, и в журнале трассировки на сервере переднего плана появится запись "connected host has failed to respond" («подключенный узел не дал ответа»)

Рис. 6. Project Web Access не может подключиться к Project Server

Службы MOPS и учетные записи служб

После решения вопроса о связи между серверами интерфейса пользователей и баз данных должна появиться возможность доступа к Project Web Access. Ура! Теперь можно уделить внимание более сложной проблеме, касающейся MOPS. Сделайте глубокий вдох и откройте журнал событий приложений на своем сервере приложений MOPS — не удивляйтесь, если увидите тысячи и тысячи сообщений об ошибках, заявляющих "Queue system could not start" («Система очередей не смогла запуститься, как показано на рис. 7. Можно также заметить, что службы MOPS задействуют почти 100% ресурсов ЦП.

Рис. 7. The Queue system could not start

Система очередей является основой инфраструктуры приложений MOPS для вставки баз данных MOPS и обработки запросов на обновление, выполняя задачи очистки и обслуживания, а также обновляя базу данных отчетов для использования в задачах анализа данных. Это подробно описано в статье "Microsoft Office Project Server 2007 Queuing System" («Система очередей Microsoft Office Project Server 2007»). Согласно этой статье, система очередей полагается на службу Windows, реализованную в сборке Microsoft.Office.Project.Server.Queuing.exe и работающую под удостоверением администратора настройки SharePoint и учетной записи службы таймеров для доступа к базе данных настройки фермы.

При запуске служба Windows извлекает список всех SSP из базы данных настройки, включая соответствующие учетные записи администратора SSP и их зашифрованные пароли, а затем запускает дополнительный процесс Microsoft.Office.Project.Server.Queuing.exe для каждого из SSP, связанных с веб-узлами PWA, в контексте соответствующей учетной записи администратора SSP. Другими словами, Microsoft.Office.Project.Server.Queuing.exe запускает несколько экземпляров самого себя под различными учетными записями, так что общее число процессов Microsoft.Office.Project.Server.Queuing.exe, работающих на сервере приложений MOPS, равно числу SSP плюс один.

Дополнительными экземплярами процесса являются рабочие процессы очереди. Каждый отдельный рабочий процесс очереди определяет собственный набор веб-узлов PWA со связанного с ним SSP, запускает дополнительные потоки опроса для каждого из веб-узлов PWA и начинает обрабатывать установленные в очередь задачи для каждой из опрошенных баз данных веб-узлов PWA. Так работает система очередей, и это можно проверить в диспетчере задач Windows.

На сервере приложений MOPS в ферме с одним SSP, связанным с веб-узлами PWA, можно увидеть два процесса Microsoft.Office.Project.Server.Queuing.exe – один работающий от имени учетной записи администрирования настойки, а другой от имени учетной записи администратора SSP. В моей тестовой среде этими учетными записями являются WssConfigAdmin и SspConfigAdmin, как показано на рис. 8.

Рис. 8. Сбой связи между процессами из-за отказа в доступе

Так почему же система очередей не запускается? Запись об ошибке в событии приложения не предоставляет достаточной информации, но дополнительные сведения о ней можно получить, если установить уровень сообщений о наименее важных ошибках в журнале трассировки на «подробный» на вкладке операций области ведения журнала диагностики в центре администрирования SharePoint 3.0.

На рис. 8 показан получившийся журнал трассировки, а если взглянуть на него ближе, то можно увидеть, что ProjectQueueService (общая служба Window) запускает QueueExecService (рабочий процесс очереди), но процесс QueueExecService терпит сбой из-за отказа в доступе. Когда это происходит с QueueExecService, ProjectQueueService пытается перезапустить его, но опять же терпит сбой по той же самой причине, в результате чего время процессора продолжают расходоваться, а журналы событий и трассировки заполняются тысячами ошибок. Это бесконечный цикл.

Увы, даже самый подробный журнал трассировки не открывает конкретную причину ошибки отказа в доступе. Но не отчаивайтесь – главную причину может быстро выявить процесс отсева.

Если изменить учетную запись администратора SSP в центре администрирования SharePoint 3.0 и указать учетную запись администрирования настройки (WssConfigAdmin), то система очередей запустится. Это также работает в обратную сторону, можно просто оставить учетную запись администратора SSP неизменной (SspConfigAdmin) и использовать ее как учетную запись службы для службы Windows, система очередей также запустится.

Тогда оказывается логичным, что и учетная запись администрирования настройки, и учетная запись администратора SSP требуют полномочий; просто система очереди не запускается, если ProjectQueueService и QueueExecService используют различные учетные записи.

Это ясное указание на проблему с полномочиями между различными процессами, желающими взаимодействовать друг с другом на локальном компьютере. В конце концов, ProjectQueueService и QueueExecService должны наблюдать друг за другом, чтобы гарантировать единообразное поведение службы (отметьте записи ProcessWatcher в журнале трассировки на рис. 8). Например, при отключении службы Windows ProjectQueueService должны отключиться и рабочие процессы QueueExecService.

К ошибке ведет попытка получить доступ к процессу, работающему в ином контексте безопасности. Доступ к процессу в ином контексте безопасности требует повышенных полномочий. Хотя учетная запись службы и может иметь эти полномочия, Windows Server 2008 все так же отказывает в доступе, поскольку контроль учетных записей пользователей (User Account Control – UAC) по умолчанию включен, что заставляет процессы работать со стандартным уровнем полномочий.

Как только UAC отключен, ProjectQueueService и QueueExecService получают возможность работать с повышенными полномочиями, и система очередей запускается. Пользователь может выбрать, использовать ли учетную запись администрирования настройки как учетную запись администратора для всех SSP, выполняя тем самым все процессы с помощью одной и той же учетной записи, либо ослаблять безопасность на серверах приложений MOPS путем отключения UAC.

Материалы по SharePoint

• SharePoint Products and Technologies Web Site
  microsoft.com/sharepoint
  
• Технический центр служб Windows SharePoint
  technet.microsoft.com/windowsserver/sharepoint
  
• Центр разработчиков служб Windows SharePoint
  msdn.microsoft.com/windowsserver/sharepoint
  
• Общий справочник по Microsoft Office Project 2007
  msdn.microsoft.com/library/bb258902
  
• Блог группы продуктов и технологий SharePoint
  blogs.msdn.com/sharepoint
  
• Планирование для административных и служебных учетных записей (Office SharePoint Server)
  technet.microsoft.com/library/cc263445
  

Интеграция служб анализа

Давайте завершим эту статью рассказом о проблеме служб анализа SQL Server 2005, с которой легко столкнуться, если следовать указаниям, описанным в "Requirements for using SQL Server 2005 Analysis Services with the Project Server 2007 Cube Building Service" («Требования к использованию служб анализа SQL Server 2005 со службой построения кубов Project Server 2007») (датировано 2007-04-05 на время написания данной статьи). Если проследовать задокументированному пути создания хранилищ служб анализа путем создания базы данных SQL Server 2005, при попытке построить куб в PWA, получится ошибка, отображенная на рис. 9.

Рис. 9. Ошибка при построении куба из-за неверной информации служб анализа

Важным моментом здесь является то, что MOPS 2007 разработан для служб анализа SQL Server 2000. Службы анализа SQL Server 2005 требуют дополнительных действий по настройке для обеспечения обратной совместимости. В версии SQL Server 2000 хранится информация о хранилище, касающаяся куба, построенного в базе данных Microsoft Jet, и хотя базу данных Jet возможно перенести для работы SQL Server 2005, она необязательна в свежем развертывании MOPS.

В статье TechNet, на которую я только что сослался, рассказано, как настраивать SQL Server 2005 на имитацию функций базы данных Jet вне зависимости от того, присутствует ли база данных Jet реально или нет. Однако в статье забыли упомянуть, что MOPS по-прежнему проверяет блокировку хранилища информации в общем файловом ресурсе DSO на сервере базы данных вне зависимости от того, настроены ли службы анализа на использование базы данных Jet (старый метод) или заранее настроенной базы данных SQL Server 2005 (предпочитаемый метод).

Пока этот общий файловый ресурс не создан и учетной записи администратора SSP не дан полный контроль над доступом к нему, процесс построения куба оканчивается сбоем, выдавая ошибку, отображаемую на рис. 9. Чтобы службы анализа SQL Server 2005 правильно функционировали со службой построения куба MOPS, выполните действия, подчеркнутые в сопровождающей таблице "Configuring Cubes" («Настройка кубов»).

Заключение

Развернуть MOPS 2007 непросто. Его архитектура сложна, и успешное развертывание состоит из многих этапов, начиная с правильного планирования настройки фермы серверов, установки двоичных файлов и выполнения работы мастера настройки продуктов и технологий SharePoint на серверах приложений и серверах веб-интерфейса, продолжая предоставлением пулов приложений, общих служб, веб-узлов администрирования SSP и веб-узлов PWA в центре администрирования SharePoint 3.0 и заканчивая настройкой служб анализа в SQL Server Management Studio.

Увеличивает сложность развертывания вмешательство функций безопасности Windows Server 2008, таких как брандмауэр Windows и UAC, слабости средств администратора SharePoint и пропуски в документации по развертыванию MOPS. Нельзя полагаться на центр администрирования SharePoint 3.0 в плане предупреждения о том, что пулы приложений используют учетную запись сетевой службы в ферме серверов, или автоматического применения всех требуемых изменений настройки (таких, как привязки веб-узла IIS и правила брандмауэра Windows), или проверки рабочего состояния предоставленных веб-узлов PWA.

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

Несмотря на эти проблемы, MOPS также наследует достоинства SharePoint как корпоративной платформы. Полагаясь на SharePoint и технологии веб-служб, MOPS устраняет потребность в прямом подключении клиентских рабочих станций к базе данных. Через систему очередей MOPS повышает устойчивость в часы пик (по каким-то необъяснимым причинам все руководители программ обновляют свои планы проектов в понедельник утром), и через дополнительные технологии MOSS его можно интегрировать с дальнейшими бизнес-приложениями.

В прошлом я занимался разработкой бизнес-решений для Project Server 2003, и нахожу проблемы развертывания MOPS 2007 минимальными по сравнению с прошлыми заботами с масштабируемостью, подключением ODBC через медленную сеть, а также неприятностями с созданием очередей баз данных, включавших столько операторов JOIN, что мне приходилось использовать Excel для отслеживания всех подзапросов. MOPS 2007 — важная веха в эволюции EPM, и он стоит усилий по развертыванию.