Ситуация, когда в рамках одной группы компаний или между разными подразделениями сосуществуют несколько независимых баз 1С:Документооборот (1С:ДО), встречается довольно часто. Основная сложность возникает, когда бизнес-процесс (например, согласование договора) начинается в одной базе, но требует участия сотрудников, работающих исключительно в другой базе. При этом заказчик хочет, чтобы сотрудники не «прыгали» между окнами, а видели задачи и документы в своем привычном рабочем окружении.
В этой статье мы подробно разберем, как реализовать совместное прохождение документов через согласование, используя различные технические подходы: от веб-сервисов до распределенных информационных баз (РИБ).
Этот метод считается наиболее гибким, так как он позволяет связать базы разных версий (например, КОРП и ПРОФ) без приведения их к полной идентичности. Основная логика заключается в создании «зеркальных» задач.
Рассмотрим по шагам, как выстроить такую архитектуру:
Пользователи, ФизическиеЛица и СтруктураПредприятия должны быть синхронизированы. Рекомендуется использовать Конвертацию данных 2.0/3.0, чтобы перенести элементы с сохранением их уникальных идентификаторов (GUID).Пример логики на стороне базы «А»:
// Пример вызова веб-сервиса другой базы
Определение = Новый WSОпределения(URL_ВебСервиса, Логин, Пароль);
Прокси = Новый WSПрокси(Определение, "http://www.uri.org", "RemoteApproval", "RemoteApprovalSoap");
ПараметрыЗадачи = Новый Структура;
ПараметрыЗадачи.Вставить("DocumentID", Строка(ДокументСсылка.УникальныйИдентификатор()));
ПараметрыЗадачи.Вставить("UserGUID", Строка(Сотрудник.УникальныйИдентификатор()));
ПараметрыЗадачи.Вставить("TaskDescription", "Согласуйте договор №" + ДокументСсылка.Номер);
Результат = Прокси.CreateExternalTask(ПараметрыЗадачи);
Проанализируем встроенные возможности 1С:ДО. В программе существует стандартный веб-сервис DMService. Обычно он используется для интеграции с ERP или УТ, но его можно адаптировать для связки «ДО — ДО».
Суть подхода заключается в том, что в одной базе (например, ПРОФ) вы можете программно реализовать клиентскую часть библиотеки интеграции. Это позволит пользователям базы ПРОФ видеть список задач из базы КОРП прямо в своей форме, открывать карточки документов и выполнять задачи. Плюсом этого решения является то, что данные физически не дублируются — они читаются «на лету» из основной базы через веб-сервис.
Если заказчик готов к организационным изменениям, можно рассмотреть вариант с РИБ. Однако здесь есть существенное ограничение, которое упоминалось в обсуждении: РИБ требует полной идентичности конфигураций.
Если одна база КОРП, а другая ПРОФ, вам придется:
Rls — Ограничение доступа на уровне записей).В этом случае документы будут мигрировать между базами автоматически. Сотрудник в узле «Б» увидит документ, созданный в узле «А», только если он включен в рабочую группу этого документа или является участником процесса. Это самый «чистый» вариант с точки зрения целостности данных, но он требует одинаковых лицензий и версий конфигурации.
Выясним, как лучше поступить с файлами (сканами документов, проектами договоров), так как их передача через веб-сервисы в виде двоичных данных может существенно замедлить работу системы.
Оптимальное решение: Использование общих томов хранения файлов. Рассмотрим этот процесс подробнее:
Это гарантирует, что сотрудник во второй базе откроет именно тот файл, который был прикреплен в первой, без нагрузки на каналы связи и лишнего дублирования данных на диске.
Проанализировав опыт разработчиков, можно сделать вывод, что наиболее стабильно работает схема с шиной данных или асинхронным обменом. Если одна из баз будет временно недоступна (например, из-за технических работ), прямой вызов веб-сервиса выдаст ошибку, и процесс согласования встанет.
Поэтому рекомендуем реализовать «очередь сообщений»:
Такой подход обеспечивает гарантированную доставку задач и отказоустойчивость системы, что критически важно для документооборота крупного предприятия.