Исходники и техническая документация: URC_Remote1C на GitHub.

У программиста 1С есть довольно привычная ситуация: работаешь в одной базе, а нужные данные лежат в другой. Нужно добавить их в отчёт, проверить документ перед загрузкой или обновить несколько реквизитов. Если всё настроено в Windows, часто выручает COM-соединение. Подключился к нужной базе, выполнил запрос, получил ссылку, прочитал объект. Дальше занимаешься своей задачей.

Удобство здесь в том, что для нового отчёта не приходится сначала создавать в другой базе отдельный способ выдачи данных. Программный доступ к ней уже есть. Можно сразу думать о том, что нужно получить и как это использовать.

Хочется сохранить эту возможность и в среде, где привычного COM нет. Именно такая идея лежит в основе URC_Remote1C: дать разработчику готовый доступ к другой базе через HTTP, с понятными действиями над запросами, ссылками и объектами.

Проект распространяется бесплатно. Ниже расскажу, какую повторяющуюся работу он помогает убрать и кому может пригодиться.

Почему к COM так легко привыкнуть

COM-соединение удобно тем, что за ним видна обычная база 1С. Мы знаем, как выполнить запрос, найти нужный элемент справочника, получить объект документа и изменить его. Через соединение делаем знакомые вещи, только обращаемся к другой информационной базе.

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

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

Конечно, COM тоже требует настройки. Но когда подключение работает, подготовка следующей интеграции обычно становится гораздо проще. Именно к этому удобству мы и привыкаем.

В Linux привычный путь меняется

COM-соединение использует возможности Windows. Создать привычный V83.COMConnector в процессе 1С, работающем под Linux, таким же способом не получится. При этом сами задачи остаются прежними: данные из другой базы всё так же нужны, объекты всё так же надо читать и записывать.

Здесь есть существенная оговорка: сервер целевой базы может работать на Linux, а COM-подключение к нему инициироваться из Windows. Ограничение проявляется именно там, где мы создаём COM-объект. Для интеграции, которую нужно выполнять из Linux, требуется другой способ доступа.

Часто таким способом становится HTTP. Платформа 1С поддерживает HTTP-сервисы, и на их основе можно организовать нужное взаимодействие.

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

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

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

Один интерфейс для разных задач

URC_Remote1C предлагает именно такой подход. В удалённой базе появляется готовый HTTP-интерфейс для основных операций, а в вызывающей базе — готовые методы работы с ним.

После установки и настройки расширения можно выполнять запросы, читать реквизиты, получать объекты по удалённым ссылкам, изменять и записывать справочники и документы. Для этих действий интерфейс уже реализован в проекте.

Если для отчёта понадобился другой запрос, пишем этот запрос в прикладном коде и вызываем готовый метод. Отдельный HTTP-обработчик в базе-источнике для него создавать не требуется. Если понадобилось прочитать ещё один поддерживаемый объект, используем тот же механизм доступа.

Здесь и находится основная польза решения: для каждой новой задачи не нужно заново разрабатывать HTTP-интерфейс источника и клиентскую обвязку к нему. Общая часть уже подготовлена. Разработчик занимается логикой своей интеграции.

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

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

Что остаётся знакомым после COM

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

• обратиться к нужной базе;
• выполнить запрос и получить данные;
• получить ссылку на интересующий объект;
• прочитать его реквизиты или сам объект;
• внести изменения и записать результат.

Имена и вызовы методов отличаются от COM, но смысл действий привычный. Не нужно для каждого сценария придумывать собственную команду вроде «вернуть данные для отчёта номер три» или «изменить комментарий документа определённого вида».

Допустим, нужно проверить документ другой базы. Можно найти его удалённую ссылку, получить данные и выполнить проверку в своём коде. Если задача предполагает изменение, получить редактируемые данные объекта, поменять нужный реквизит и отправить запись. Для документов предусмотрены также проведение и отмена проведения — при соответствующих разрешениях.

В этом смысле URC_Remote1C может стать практической заменой COM-соединению в таких интеграциях. Знакомая модель работы сохраняется, а обращение между базами идёт через HTTP.

Старый COM-код при переходе нужно адаптировать к методам расширения. Полного совпадения всех возможностей COM здесь нет. Зато основные действия, ради которых мы часто открываем соединение с другой базой, собраны в одном инструменте.

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

Где это может пригодиться

Отчёт с данными из нескольких баз. В одной базе формируется отчёт, а часть показателей хранится в другой. Через готовое подключение можно получить нужные данные и добавить их в расчёт. При изменении состава показателей дорабатывается прикладная логика отчёта; отдельный серверный интерфейс для каждого варианта выборки не требуется.

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

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

Переход интеграций с Windows на Linux. Если обработка строилась вокруг COM, при переносе меняется способ доступа к другой базе. URC_Remote1C позволяет сохранить знакомую логику операций: запросить данные, получить объект, изменить и записать. Сам код обращения потребуется адаптировать, а повторную разработку транспортной части можно сократить за счёт готовых методов.

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

Когда нужен вызов своей серверной логики

Запросов и работы с объектами хватает для многих повседневных задач. Иногда требуется выполнить в другой базе собственную функцию: сделать прикладной расчёт или обработать данные по правилам этой конфигурации.

Для этого в URC_Remote1C предусмотрен вызов заранее зарегистрированных серверных функций. Разработчик готовит функцию в удалённой базе, а затем разрешает её вызов под определённым именем. Со стороны клиента используется общий механизм обращения.

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

Клиент вызывает разрешённую функцию с параметрами. Произвольный текст программы через этот интерфейс не передаётся. Это позволяет явно определить, какую серверную логику можно использовать извне.

Сколько работы нужно для начала

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

Для текущей версии используются возможности платформы 8.3.26 и новее. Полные требования, порядок установки и примеры вызовов приведены в документации проекта.

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

Отдельно стоит настроить права. Удалённые операции выполняются от имени пользователя HTTP-сервиса. Расширение позволяет разрешать чтение, отдельно включать запись и ограничивать типы записываемых объектов. Права самой конфигурации продолжают действовать.

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

Что стоит учитывать при выборе

URC_Remote1C даёт синхронный доступ к другой базе: отправили обращение и дождались результата. Расписание обменов, очередь заданий и правила повторной обработки разработчик организует в своём решении, если они нужны.

Работа через HTTP также заставляет внимательнее относиться к количеству обращений. Для отчёта обычно разумнее получить необходимую выборку одним запросом, чем отдельно читать каждый реквизит каждого объекта. Готовые методы упрощают обращение, но объём передаваемых данных по-прежнему определяется нашей задачей.

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

Таймаут соединения тоже требует внимания. Если клиент не дождался ответа на запись, это ещё не означает, что сервер ничего не записал. Перед повтором нужно выяснить результат первой операции. Подробности такого поведения описаны в руководстве.

Эти особенности полезно знать до использования инструмента. Они помогают выбрать подходящую задачу и правильно встроить удалённые вызовы в свой код.

С чего я предлагаю начать

Возьмите одну небольшую задачу, для которой обычно использовали бы COM или написали собственный HTTP-сервис. Например, чтение данных другой базы для отчёта или проверку существования объекта перед обменом.

Подготовьте подключение на тестовых базах и попробуйте решить её через URC_Remote1C. Посмотрите, какой объём кода относится к самой задаче и сколько дополнительной работы потребовалось для обращения к источнику.

Если вам близок подход «подключиться к базе и работать с её данными», проект стоит попробовать. Особенно если хочется продолжать писать привычный код 1С в среде, где создание COM-соединения недоступно.

Главная идея URC_Remote1C — сделать доступ к другой базе повторно используемым инструментом. Чтобы при появлении следующего отчёта или обмена можно было сразу заниматься запросами и объектами, используя уже подготовленный интерфейс.

Исходники и техническая документация доступны в репозитории URC_Remote1C в ветке main. Скачать исходники можно через Code → Download ZIP. В репозитории также находится файл расширения CFE и руководство для дальнейшего знакомства.