ADG Оставить заявку
Блог Интеграции 4 мин чтения

SharePoint 2007 SP2: обновили корпоративный портал и разгребали кастомные веб-части

Обновление SharePoint 2007 до SP2 принесло нормальную поддержку IE8, но несколько кастомных веб-частей сломались. Документируем зависимости и порядок проверки.

Контекст момента

SharePoint 2007 SP2 вышел в апреле 2009 - исправления платформы и улучшенная совместимость с IE8

SP2 для SharePoint 2007 вышел ещё в апреле, но применять его сразу на боевой портал клиента никто не спешил. Логика понятна: большой сервис-пак, кастомных решений накоплено достаточно, стенда в натуральную величину нет. Пролежало полгода в очереди - и только сейчас дошли руки сделать всё по-человечески.

Зачем вообще обновляться

Главная боль последних месяцев - Internet Explorer 8. Microsoft выкатила его в марте, корпоративные машины клиента начали на него переезжать через групповые политики, и портал стал вести себя странно: слетала вёрстка в ряде страниц, некоторые диалоговые окна не открывались, DataView Web Part рендерился с артефактами. Всё это потому, что оригинальный SharePoint 2007 выходил под IE6/IE7, IE8 он не знал.

SP2 закрывает именно это. Плюс пачка накопленных патчей безопасности и несколько исправлений в поиске и документ-библиотеках, которые сами по себе уже давно напрашивались.

Подготовка

Перед обновлением сделали инвентаризацию того, что вообще живёт на портале. Это оказалось полезнее, чем ожидалось, - несколько веб-частей числились «стандартными», а по факту были сторонними сборками под конкретные версии WSS 3.0.

Список зависимостей получился примерно такой:

  • Кастомные веб-части - три штуки, написанные под конкретный проект, с жёстко зашитыми путями к assembly.
  • Сторонние компоненты - два продукта от внешних вендоров, один из которых не обновлялся с 2007 года.
  • Тема оформления - кастомная, с переопределёнными CSS-файлами через _layouts.
  • Рабочие процессы SharePoint Designer - несколько, завязанных на конкретные списки.

Полного тест-стенда не было, поэтому сделали снапшот виртуальной машины (портал живёт на VMware ESX) и развернули копию базы контента на отдельный SharePoint в тестовом домене. Не идеально, но лучше, чем катить вслепую.

Само обновление

Процедура стандартная для SharePoint - запуск инсталлятора SP2, потом обязательный PSConfig для обновления баз. Вот тут первая засада: PSConfig завершился с ошибкой на одной из баз контента. Оказалось, в базе были сиротские записи от старой веб-части, которую удалили не через UI, а просто снесли файлы. SharePoint это не простил.

Починили руками через stsadm, почистили осиротевшие feature-записи, запустили PSConfig повторно - прошло чисто.

Что сломалось

После обновления портал поднялся, большинство функций работало нормально. IE8 действительно перестал глючить на стандартных страницах. Но три кастомные веб-части встретили нас белым экраном с ULS-ошибками в логах.

Первая веб-часть использовала устаревший способ получения контекста через SPContext.Current внутри асинхронного кода - в SP2 это поведение ужесточили. Пришлось рефакторить с передачей контекста явно.

Вторая тянула библиотеку, которая была скомпилирована под .NET 2.0 без учёта новых сборок WSS 3.0 SP2. Перекомпилировали с обновлёнными референсами - заработало.

Третья - самая неприятная. Это была сторонняя веб-часть для визуализации KPI, которую клиент купил года два назад. Вендор обновлений не выпускал, а она завязана на internal API SharePoint, который в SP2 немного изменился. Связались с вендором - ответа нет. Пришлось временно заменить на кастомный DataView с XSLT-трансформацией, который хотя бы отображает данные без красивостей.

Про документирование зависимостей

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

Теперь ведём таблицу: компонент, версия, источник (встроенный / кастомный / сторонний), дата последнего обновления от вендора, совместимость с текущей версией SharePoint. Банально, но раньше этого не было.

Работу по интеграции SharePoint с корпоративными системами мы ведём регулярно, и каждый раз убеждаемся, что платформа тянет за собой длинный хвост зависимостей. SP2 в этом плане показательный случай: само обновление прошло быстро, разбор последствий занял в несколько раз больше.

Портал сейчас работает стабильно, IE8 перестал быть источником жалоб. Вопрос с KPI-виджетом пока открыт - ждём ответа от вендора, параллельно оцениваем альтернативы.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.