Как организовать обмен данными в 1С 7.7 между разными конфигурациями при плохом качестве интернета

← На главную

Проблема организации обмена данными в среде 1С:Предприятие 7.7 осложняется тем, что штатные механизмы (УРИБ) жестко завязаны на идентичность конфигураций. Если же нам необходимо передавать данные из удаленных офисов с одной структурой в центральную базу с совершенно другой структурой, да еще и в условиях крайне нестабильного интернет-соединения, стандартные решения перестают работать. Рассмотрим подробно, как выстроить надежную систему обмена, используя проверенные временем инструменты и современные способы доставки пакетов.

Выбор механизма выгрузки и загрузки данных

Первый вопрос, который нам необходимо решить — это как «вынуть» данные из одной конфигурации и «вложить» их в другую. Поскольку конфигурации различаются, обычный УРИБ нам не подходит. Разберем основные варианты.

1. Универсальный обмен данными через XML. Рассмотрим использование обработки V77Exp.ert, которая работает в связке с конфигурацией «Конвертация данных 2.0». Несмотря на то, что сама КД 2.0 работает на платформе 8.x, она позволяет создавать правила обмена для 7.7. Проанализируем этот путь: мы описываем сопоставление объектов в визуальном редакторе на платформе 8, выгружаем правила в файл XML и подключаем их в 1С 7.7. Это наиболее гибкий метод, позволяющий программно описывать логику сопоставления реквизитов любой сложности.

2. Использование специализированных надстроек (МОД и аналоги). Посмотрим на «Менеджер обмена данными» (МОД). Это мощный инструмент, который добавляет в конфигурацию собственные объекты для регистрации изменений. Однако, как отмечают эксперты, МОД может быть избыточен и сложен в поддержке. Рассмотрим альтернативу — «Универсальный обмен данными для 1С 7.7». Проанализируем его преимущества: он работает стабильнее МОД, не требует таких масштабных изменений в коде конфигурации и позволяет эффективно сопоставлять справочники и документы по внутренним идентификаторам или кодам.

3. Комбинированный метод (УРИБ + Ручной разбор). Выясним причину популярности этого метода. Мы можем использовать штатный механизм УРИБ только для регистрации изменений (чтобы платформа сама помечала, какие объекты изменились), но выгрузку делать собственным скриптом в формат XML или DBF. Это позволяет избежать проблем с коллизиями при загрузке в разные конфигурации.

Организация транспорта в условиях плохого интернета

Когда пакет обмена сформирован, встает задача его доставки. При плохом интернете VPN часто «отваливается», а FTP-соединение рвется на середине файла. Разберем шаги по оптимизации передачи данных.

Использование облачных сервисов и P2P-синхронизации. Рассмотрим такие инструменты, как Яндекс.Диск или Syncthing. Проанализируем ситуацию: эти приложения работают как фоновые службы. Они умеют докачивать файлы после разрыва связи, используют эффективные алгоритмы хеширования и не требуют поднятия сложной сетевой инфраструктуры. Для 1С это выглядит просто как запись файла в определенную папку на диске.

Дробление файлов и архивация. Обязательно упаковываем файлы обмена. Для этого из 1С можно вызвать консольную версию Rar.exe или 7z.exe. Посмотрим на пример кода для вызова архиватора:


КомандаСистемы("C:\Progra~1\WinRAR\Rar.exe a -m5 -v500k " + ПутьКАрхиву + " " + ПутьКФайлуОбмена);

В данном примере параметр -v500k создаст многотомный архив по 500 килобайт. Это критически важно для плохого интернета: если передача одного тома сорвется, система переотправит только его, а не весь огромный файл целиком.

Реализация обмена через HTTP-запросы

Если нам нужно более управляемое решение, чем облачный диск, мы можем реализовать передачу через объект WinHttp.WinHttpRequest.5.1. Это позволит отправлять данные напрямую на веб-сервер центральной базы. Рассмотрим подробнее алгоритм:

Центральная база имеет «белый» IP или доступ через проброс портов.
На стороне центральной базы развернут простейший скрипт (например, на PHP или Python), принимающий POST-запросы.
Удаленная база отправляет файл частями, используя HTTP-протокол.

Проанализируем пример кода для отправки данных из 1С 7.7:


Попытка
    WinHttp = СоздатьОбъект("WinHttp.WinHttpRequest.5.1");
    WinHttp.Open("POST", "http://my-center-base.ru/upload.php", 0);
    WinHttp.SetRequestHeader("Content-Type", "application/octet-stream");
    WinHttp.Send(ТекстФайлаОбмена);
    Если WinHttp.Status = 200 Тогда
        Сообщить("Файл успешно отправлен");
    КонецЕсли;
Исключение
    Сообщить("Ошибка связи: " + ОписаниеОшибки());
КонецПопытки;

Архитектурная хитрость: База-шлюз

Разберем еще один эффективный сценарий. Чтобы не нагружать центральную базу (ЦБ) разбором тяжелых XML от четырех удаленных баз, мы можем создать в центре «базу-шлюз». Эта база будет иметь идентичную удаленным базам конфигурацию. Обмен между ними настраивается через стандартный УРБД (который отлично жмет данные и работает по номерам сообщений). А уже внутри центрального офиса, в локальной сети, мы настроим перенос данных из базы-шлюза в основную ЦБ через OLE или прямой SQL-запрос. Это разделит проблему транспорта и проблему трансформации данных.

Важные рекомендации по надежности

При работе в условиях «плохой канализации» (как называют плохой интернет связисты), необходимо соблюдать правила квитирования (подтверждения):

Номер сообщения: Каждому пакету присваивается уникальный номер.
Ожидание подтверждения: Удаленная база не должна снимать пометку «изменено» с объектов до тех пор, пока из центра не придет файл-ответ с подтверждением успешной загрузки именно этого номера пакета.
Контрольные суммы: Перед отправкой и после получения файла проверяйте его целостность (например, через расчет MD5), чтобы исключить повреждение данных при обрыве сессии.

Выясним, какой способ в итоге выбрать? Если вы хотите минимум программирования — используйте Syncthing для доставки файлов и Универсальный обмен данными для их обработки. Если нужна максимальная автоматизация и есть навыки веб-программирования — смотрите в сторону HTTP POST запросов с дроблением архивов на мелкие части.