Что проверить перед настройкой бесшовной интеграции 1С:Документооборот 3.0 с учетной системой

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

Чтобы такие препятствия не возникали в середине проекта, технические требования и ограничения заказчика нужно обсудить заранее. В статье разберём, что проверить перед настройкой бесшовной интеграции 1С:Документооборот 3.0 с учетной системой и какие вопросы согласовать с ИТ-службой и службой безопасности.

Как работает бесшовная интеграция
Почему требования упускают на старте
Что изменилось в бесшовной интеграции 1С:Документооборот 3.0
Что проверить перед настройкой бесшовной интеграции
Кейс: согласование публикации баз со службой безопасности
Выводы

В каждой учетной системе свои виды документов: заявки на оплату, договоры, кадровые переводы, акты. Когда они проходят согласование и утверждение в одной системе, пользователям проще, а компании проще контролировать процесс. Бесшовная интеграция как раз для этого: документ создается в учетной системе, а его согласование проходит в 1С:Документооборот 3.0, и статус возвращается обратно.

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

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

Последствия понятны: сдвигаются сроки, проект простаивает в ожидании решений от службы безопасности и ИТ-инфраструктуры, а иногда приходится менять архитектуру решения.

В версии 2.1 для бесшовной интеграции достаточно было опубликовать на веб-сервере только базу 1С:Документооборот (далее ДО): учетная система обращалась к ней сама. В 3.0 схема другая: на веб-сервере должны быть опубликованы обе базы. Причина в архитектуре: интегрируемая система тоже требует публикации, а в 1С:Документообороте прописываются адреса публикаций таких систем, чтобы ДО обращалось к ним напрямую.

Второе отличие: в 2.1 правила настраивались только на стороне базы-отправителя, например ERP. В 3.0 настройка выполняется в обеих базах, а правила загрузки данных в ДО задаются на стороне документооборота, причем начинать лучше с него.

Это важно для заказчика с жесткой безопасностью. Нужно согласовать публикацию обеих баз, и ДО должен «видеть» учетную систему.

Подойдет любой веб-сервер, поддерживаемый платформой 1С, чаще всего это IIS или Apache. Бесшовная интеграция работает через веб-сервисы, поэтому без веб-сервера ее не будет. Обе базы могут стоять на одном сервере или на разных. Главное, чтобы адреса публикаций были доступны друг для друга по сети.

Публикация выполняется из конфигуратора пользователем с правами администратора, в ней нужно отметить публикацию веб-сервисов, включая DMService. После публикации проверьте доступность описания веб-сервиса по его адресу с параметром ?wsdl. Публикуйте обе базы: частая ошибка в том, что публикуют только одну.

Отдельных требований именно к бесшовной интеграции нет. Сервер подбирают так же, как для любого внедрения 1С: по конфигурации, числу одновременно работающих пользователей, размеру базы с запасом на 2-3 года и особенностям нагрузки. Бесшовная интеграция добавляет к этому веб-сервер, обмен сообщениями по расписанию и передачу файлов между базами. Размер передаваемого файла по рекомендациям внедренцев стоит ограничить 10–15 МБ, чтобы не перегружать сервер.

Ориентиры по ресурсам для малого, среднего и крупного внедрения приведены в методических рекомендациях 1С (таблица 1). Это усреднённые рекомендации: оборудование для конкретного проекта нужно подбирать с учётом нагрузки и проверять нагрузочным тестированием. Есть и несколько практических правил. Сервер системы управления базами данных (СУБД) не должен выполнять других ролей, а на сервере 1С не стоит размещать роль терминального сервера. Файлы баз данных, логи и временные файлы кластера лучше хранить на быстрых SSD. Размещение серверов в одной подсети рекомендуется, но не является обязательным условием работы бесшовной интеграции.

При выборе сетевой схемы нужно учитывать возможные задержки при передаче данных.

Источник: 1С:ИТС. Расчет параметров серверного оборудования.

У каждого релиза ДО есть минимальная версия платформы. Например, для 3.0.7 это 8.3.17.2306. Сверяйте требования по вашему релизу. Бесшовная интеграция предусмотрена в ряде типовых конфигураций, список есть в документации к релизу, а Библиотеку интеграции с ДО (БИД) можно встроить и в собственную конфигурацию на платформе. Если конфигурация нетиповая, нужно отдельно выяснить, есть ли в ней БИД и какой версии.

Здесь часто ошибаются в обе стороны: дают слишком мало, и интеграция не работает, или слишком много, и это не нравится службе безопасности. В инструкциях партнеров рекомендуется так: настройка выполняется под пользователем с полными правами, а для обращения к веб-сервису используется служебный пользователь с ограниченными полномочиями. В учетной системе такому пользователю назначают, например, профиль с базовыми правами конфигурации, базовыми правами БИД и ролью «Пользователь обмена с ДО». Права служебного пользователя не должны быть избыточными. В форме подключения указываются адрес публикации, имя пользователя и пароль, поэтому заранее нужно решить, кто создает этого пользователя и как хранится его пароль.

Документ в ДО должен получить ответственных и участников. Желательно, чтобы сотрудники были заведены в обеих системах. Перед настройкой интеграции стоит настроить синхронизацию нормативно-справочной информации (НСИ). Для связки с 1С:ERP порядок настройки разобран в статье «Обмен НСИ с 1С:ERP в 1С:Документооборот». Если подходящего сотрудника в ДО не найдется, система попытается его создать, но без данных о подразделении сделать это не сможет и выдаст ошибку.

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

При появлении 3.0 бесшовная интеграция была реализована в ограниченном объеме, часть возможностей версии 2 отсутствовала. До начала настройки проверьте, поддерживают ли используемые релизы все необходимые сценарии работы: какие документы нужно передавать, как запускать их согласование и какие данные должны возвращаться в учетную систему. Это поможет заранее выявить ограничения и понять, потребуются ли доработки.

На проекте внедрения бесшовной интеграции 1С:ERP и 1С:Документооборот 3.0 команда проектировала правила загрузки, схемы согласования, настраивала виды документов. Все шло по плану.

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

Службе безопасности передали материалы по безопасности публикации баз на серверах заказчика. После проверки публикацию согласовали.

Интеграцию внедрили, но согласование заняло время, которое не планировалось. Проблему решила коммуникация с заказчиком, но так бывает не всегда. Если бы договориться о публикации не удалось, пришлось бы разрабатывать альтернативный вариант интеграции. Это дополнительные трудозатраты, которые в проекте обычно не закладываются.

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

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