SharePoint 2007: внедряем документооборот и упираемся в инфраструктуру

Задача пришла от клиента - средняя производственная компания, отдел закупок согласует договоры через почту и общий диск. Классика: версии файлов с именами вроде «договор_ФИНАЛ_v3_правки_Иванова_2.doc», никакой истории, непонятно кто и когда дал добро. Клиент слышал про SharePoint, Microsoft активно продвигает его как платформу для именно таких задач - и вот мы разворачиваем MOSS 2007 в лабе, чтобы понять, что реально получится.

Что такое MOSS 2007 в контексте документооборота

Microsoft Office SharePoint Server 2007 - это не просто файловый сервер с веб-интерфейсом. Там есть библиотеки документов с версионированием, списки задач, и главное - механизм workflow. Из коробки доступно несколько стандартных процессов: согласование (Approval), сбор подписей, уведомление об изменениях. Для несложных маршрутов этого хватает - несколько согласующих, последовательно или параллельно, с уведомлениями по почте.

Для чего-то сложнее - нестандартные условия ветвления, интеграция с внешними системами - нужен SharePoint Designer 2007. Бесплатный инструмент от Microsoft, позволяет строить workflow визуально: условие - действие - ветка. Без написания кода, что теоретически делает его доступным для бизнес-аналитика, а не только разработчика.

Мы взяли за основу именно Designer: хотели понять предел без программирования.

Active Directory: сначала всё хорошо

SharePoint от рождения завязан на AD. Пользователи, группы, права - всё через домен. У клиента AD есть, и это сразу снимает целый пласт вопросов: не надо заводить отдельную базу пользователей, синхронизировать её, думать про SSO.

На практике это выглядит так: заходишь в настройки сайта, указываешь AD-группы («Юристы», «Финансовый директор», «Руководители направлений»), они автоматически появляются как доступные участники workflow. Пользователь заходит на SharePoint под своим доменным логином - никакой второй пароль, никакой регистрации. Это работает ровно так, как должно работать.

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

SharePoint Designer: возможности и пределы

Построение workflow в Designer оказалось доступным, но со своими особенностями. Логика выглядит примерно так: «если статус документа - "На согласовании" и сумма договора больше X - назначить задачу группе "Финансовый директор", иначе - группе "Руководители"». Условия задаются через визуальный редактор, действия выбираются из готового списка.

Что работает хорошо: последовательные и параллельные согласования, уведомления по почте, запись результата в поля документа, базовые ветвления по значениям полей.

Что упёрлось в потолок:

• Условия по полям из внешних систем - нельзя просто сделать «если клиент в статусе VIP в CRM - сделай вот это». Нужен либо промежуточный список SharePoint, куда данные из CRM синхронизируются, либо кастомный код.
• Обработка ошибок - если задача просрочена и согласующий не ответил, Designer позволяет выставить таймер и эскалировать. Но логика эскалации быстро упирается в ручной переход к коду, если нужно что-то нестандартное.
• Циклы - с повторяющейся логикой внутри одного workflow Designer справляется плохо. Обходится, но некрасиво.

Для базового маршрута «создал - на согласование юристу - на подпись директору - финализирован» Designer справился нормально. Клиенту этого хватало на 80% случаев.

SQL Server: вот где засада

Вот тут начался разговор, которого клиент не ожидал. SharePoint 2007 требует SQL Server как хранилище - всё: содержимое сайтов, конфигурация, данные workflow - живёт в SQL. Под MOSS 2007 нужен SQL Server 2005 или 2008 (мы как раз только что смотрели на RTM SQL Server 2008).

Требования к SQL-серверу для сколько-нибудь серьёзной нагрузки - это отдельный сервер, нормальные диски, резервное копирование баз SharePoint. Это не «поставили рядом на ту же машину», особенно если в перспективе больше пользователей и документов.

Клиент рассчитывал на одну машину. После диагностики нагрузки и понимания объёмов - придётся считать отдельно под SQL. Нет, это не страшно, но это деньги на лицензию SQL Server и железо, которых в бюджете «на SharePoint» изначально не было.

Кроме этого, вопрос резервного копирования: бэкап SharePoint - это бэкап SQL-баз, и делать его надо правильно, иначе при восстановлении потеряешь часть истории workflow или вообще сайт поднимется в нерабочем состоянии. Стандартный вопрос «а вы бэкапите?» тут превратился в «а вы понимаете, что именно бэкапить и как проверять восстановление?».

Где мы сейчас

Стенд работает, базовый маршрут согласования договоров - работает, AD-интеграция - работает. Итоги договорились зафиксировать отдельно после двух недель тестирования с реальными пользователями.

Самый честный вывод на сейчас: SharePoint 2007 как платформа документооборота - реальный инструмент, а не маркетинг. Но он тянет за собой инфраструктуру, и если приходить к клиенту только с «SharePoint», не обсудив SQL, резервирование и дисковую подсистему - потом будет неловко.

Если задача автоматизировать согласование документов и подобрать под это правильный стек, это входит в нашу работу по интеграции корпоративных систем.