При разработке мобильного приложения на платформе 1С, например, под названием «МобиЖЕ», часто возникает задача организации эффективного и надежного обмена данными с основной десктопной программой 1С. Особенно актуальным становится вопрос получения оперативной информации о «новых вызовах» или сообщениях, которые поступают из мобильного приложения. Ранее для таких целей могли использовать локальные решения на базе Apache, но современные требования диктуют необходимость использования облачных технологий. В данном материале мы рассмотрим различные подходы к реализации такого обмена с использованием облачных сервисов, фокусируясь на асинхронной передаче сообщений и механизмах уведомлений, которые позволят десктопной 1С оперативно получать информацию о новых событиях.
Для нашей задачи важно не просто хранить файлы, как это делают обычные облачные хранилища вроде Яндекс.Диска, а именно обмениваться событиями и сообщениями в реальном или почти реальном времени. Это требует более специализированных инструментов, чем просто синхронизация файлов.
Начнем с рассмотрения брокеров сообщений, которые являются краеугольным камнем для построения распределенных систем и обеспечения надежного асинхронного обмена данными между различными приложениями. Эти системы позволяют отправителю и получателю работать независимо друг от друга, что значительно повышает масштабируемость и отказоустойчивость всей системы. Мобильное приложение может отправлять данные в брокер, не дожидаясь их немедленной обработки десктопной программой 1С, а последняя будет получать их, когда будет готова.
RabbitMQ: Одним из наиболее известных и зрелых брокеров сообщений является RabbitMQ. Это надежная система с открытым исходным кодом, которую можно легко развернуть в облачной среде. RabbitMQ поддерживает гибкую маршрутизацию сообщений и различные протоколы, такие как AMQP (Advanced Message Queuing Protocol) и MQTT (Message Queuing Telemetry Transport). Как мы можем это использовать?
Мобильное приложение «МобиЖЕ» может публиковать документы, события или информацию о «вызовах» в определенную очередь RabbitMQ. Десктопное приложение 1С, в свою очередь, будет подписано на эту очередь. Как только новое сообщение поступает в очередь, 1С его получает и обрабатывает. Для взаимодействия 1С с RabbitMQ напрямую, возможно, потребуется использовать внешние компоненты или создавать прослойку (например, на .NET или Python), которая будет взаимодействовать с RabbitMQ и вызывать методы 1С по HTTP или COM-соединению.
Предположим, мы хотим отправить данные о новом документе из мобильного приложения через облачный сервис в RabbitMQ. Мобильное приложение 1С может выполнить HTTP-запрос к промежуточному веб-сервису, который затем передаст сообщение в RabbitMQ. С точки зрения десктопной 1С, она может периодически опрашивать этот веб-сервис или использовать внешний компонент для прослушивания очереди.
Концептуальный пример отправки сообщения из 1С через HTTP-шлюз к брокеру:
// Мобильное приложение 1С или десктопная 1С может отправить данные
// через HTTP-запрос к промежуточному веб-сервису/шлюзу,
// который затем опубликует сообщение в RabbitMQ.
// Пример данных, которые хотим отправить
СообщениеДляБрокера = Новый Структура;
СообщениеДляБрокера.Вставить("ТипСобытия", "НовыйВызов");
СообщениеДляБрокера.Вставить("ДокументGUID", "ВАШ_GUID_ДОКУМЕНТА");
СообщениеДляБрокера.Вставить("Данные", "Полное описание или ссылка на данные");
// Сериализация данных в JSON
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
JSONСериализатор.Записать(ЗаписьJSON, СообщениеДляБрокера);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Создание HTTP-запроса к нашему облачному шлюзу
HTTPЗапрос = Новый HTTPЗапрос("/publish", "api.yourcloudgateway.com"); // Указываем URL шлюза
HTTPЗапрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8, "application/json");
// Отправка запроса
Попытка
HTTPСоединение = Новый HTTPСоединение("api.yourcloudgateway.com");
HTTPОтвет = HTTPСоединение.Отправить(HTTPЗапрос);
Если HTTPОтвет.КодСостояния = 200 Тогда
Сообщить("Сообщение успешно отправлено в брокер.");
Иначе
Сообщить("Ошибка отправки сообщения: " + HTTPОтвет.КодСостояния + " " + HTTPОтвет.ПолучитьТелоКакСтроку());
КонецЕсли;
Исключение
Сообщить("Ошибка соединения с HTTP-шлюзом: " + ОписаниеОшибки());
КонецПопытки;
Apache Kafka: Если мы имеем дело с очень большими объемами данных в реальном времени и потоковой передачей событий, Apache Kafka станет мощной платформой. Kafka оптимизирована для высокой пропускной способности и устойчивости, что делает ее идеальной для сценариев, где требуется обработка миллионов событий в секунду. Это может быть избыточно для простой задачи обмена "вызовами", но полезно для систем с высокой нагрузкой.
NATS: Для легковесных и высокоскоростных облачных приложений, требующих низкой задержки, мы можем рассмотреть NATS. Это современная система обмена сообщениями, разработанная для облачных сред, которая предлагает отличную производительность и простоту.
Управляемые сервисы очередей сообщений: Крупные облачные провайдеры (например, Azure Service Bus, Tencent Cloud CMQ или CKafka для Kafka) предлагают готовые управляемые сервисы очередей сообщений. Использование таких сервисов значительно упрощает нашу работу, поскольку снимает нагрузку по управлению инфраструктурой: масштабирование, мониторинг и обслуживание ложатся на провайдера. Это позволяет нам сосредоточиться непосредственно на разработке функциональности обмена данными.
Как это работает с 1С:
Мобильное приложение 1С «МобиЖЕ» отправляет данные о «документе» или «вызове» в облачный брокер сообщений. Десктопное приложение 1С, в свою очередь, должно иметь механизм для получения этих сообщений. Это может быть:
РегламентныеЗадания для периодического опроса брокера сообщений (через промежуточный API или внешний компонент) на предмет новых данных.При получении сообщения, 1С его читает, парсит (например, из формата JSON с помощью ЧтениеJSON) и обрабатывает, создавая или обновляя соответствующие данные в своей базе.
Платформа 1С:Предприятие обладает мощными встроенными механизмами для работы с веб-сервисами, которые мы можем активно использовать для обмена данными как с мобильными клиентами, так и с облачными сервисами. Этот подход позволяет нам публиковать данные из 1С или принимать их, используя стандартные протоколы SOAP/REST.
Использование облачных веб-сервисов: Мы можем опубликовать веб-сервис непосредственно из конфигурации 1С. Мобильное приложение «МобиЖЕ» будет отправлять данные на этот опубликованный веб-сервис. Если 1С расположена в частной сети, то для доступа извне потребуется публикация через прокси-сервер, такой как Apache HTTP Server или Nginx, что является распространенной практикой. Этот веб-сервис 1С может напрямую принимать данные от мобильного клиента или же выступать в качестве конечной точки для брокера сообщений.
Концептуальный пример публикации веб-сервиса в 1С:
// В конфигураторе 1С мы определяем веб-сервис.
// Например, создаем новый объект "WebService" и определяем его методы.
// Метод может принимать XML или JSON-строку с данными.
// Пример метода веб-сервиса в модуле объекта "WebService":
Функция ПринятьНовыйВызов(ДанныеВызоваJSON) Экспорт
// ДанныеВызоваJSON - это строка JSON, которую нам прислало мобильное приложение.
// Десериализуем JSON
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ДанныеВызоваJSON);
Данные = ПрочитатьJSON(ЧтениеJSON);
// Пример обработки полученных данных:
// Мы можем создать новый документ, записать информацию в регистр или выполнить другие действия.
НовыйДокумент = Документы.НашДокумент.СоздатьДокумент();
НовыйДокумент.Дата = ТекущаяДата();
НовыйДокумент.Номер = Данные.НомерВызова;
// ... Заполняем другие реквизиты документа из Данные ...
Попытка
НовыйДокумент.Записать();
Возврат "Успешно принято и обработано: " + НовыйДокумент.Номер;
Исключение
Возврат "Ошибка при обработке вызова: " + ОписаниеОшибки();
КонецПопытки;
КонецФункции
// Для публикации на веб-сервере:
// Мы используем утилиту публикации или пункт меню "Файл -> Публикация на веб-сервере..."
// После публикации, мобильное приложение сможет вызывать этот метод через HTTP-запрос.
Для вызова веб-сервиса 1С из мобильного приложения, мы можем использовать встроенные механизмы работы с HTTPЗапрос или WSСсылки, если веб-сервис описан с WSDL.
Пример вызова веб-сервиса из 1С (мобильного или десктопного):
// Предположим, у нас есть веб-сервис "МойОбменСервис"
// и ссылка на него настроена в конфигурации.
// В противном случае можно использовать HTTPЗапрос.
// Пример использования WSСсылки:
Попытка
Прокси = WSСсылки.МойОбменСервис.СоздатьПрокси(); // Имя WS-ссылки
Результат = Прокси.ПринятьНовыйВызов("{\"НомерВызова\": \"00123\", \"Описание\": \"Тестовый вызов\"}");
Сообщить("Результат вызова веб-сервиса: " + Результат);
Исключение
Сообщить("Ошибка при вызове веб-сервиса: " + ОписаниеОшибки());
КонецПопытки;
Планы обмена 1С: Для обеспечения корректной регистрации изменений и синхронизации данных между мобильным и основным приложением 1С, настоятельно рекомендуем использовать встроенные механизмы планов обмена. Платформа 1С 8.3.6 и выше поддерживает мобильные клиенты и позволяет настраивать обмен данными, используя эти планы. В более новых версиях, например, 8.3.28, ожидаются дополнительные упрощения для работы с автономными мобильными клиентами, что делает этот подход еще более привлекательным. Планы обмена гарантируют, что только измененные данные будут передаваться, оптимизируя трафик и обеспечивая целостность информации.
Мы можем настроить план обмена, который будет фиксировать все изменения в определенных объектах (например, документах «Вызов») на стороне мобильного приложения. При синхронизации (например, по запросу или через регулярные интервалы), эти изменения будут передаваться в центральную базу 1С.
Для этого в конфигурации мы создаем объект ПланОбмена, указываем состав данных для обмена и настраиваем правила регистрации изменений.
Для реализации функционала «информация о новом вызове» или «прочитала новых сообщений» нам требуются механизмы, способные доставлять уведомления десктопному приложению 1С или вспомогательным службам, которые с ним взаимодействуют.
Firebase Cloud Messaging (FCM): Это кросс-платформенная облачная платформа для обмена сообщениями, которая позволяет надежно отправлять уведомления на мобильные (Android, iOS) и веб-приложения. Хотя FCM в первую очередь используется для мобильных и веб-уведомлений, мы можем интегрировать его в наше решение. Например, когда мобильное приложение отправляет данные в облачный брокер сообщений (как мы обсуждали выше), облачный сервис может одновременно отправить уведомление через FCM. Это уведомление будет получено вспомогательным сервисом на ПК (не самой 1С напрямую), который затем оповестит 1С о необходимости проверить новые данные. FCM является бесплатным, масштабируемым и надежным сервисом.
Схема работы может быть следующей: Мобильное приложение «МобиЖЕ» -> Облачный веб-сервис/API -> RabbitMQ + FCM. Затем FCM уведомляет небольшое приложение-слушатель на ПК, которое, в свою очередь, активирует 1С или ее регламентное задание на чтение новой информации из RabbitMQ или прямого веб-сервиса 1С.
Pusher: Это еще один облачный сервис, предоставляющий хостинговые API для технологий реального времени. Pusher отлично подходит для создания живых дашбордов, чатов и систем уведомлений. Если нам нужно отображать информацию о «новых вызовах» в каком-либо веб-интерфейсе или отдельном приложении для оператора, Pusher может стать хорошим выбором для доставки уведомлений в реальном времени.
Опрос очереди (Polling): Самый простой, но менее «мгновенный» метод получения уведомлений. Десктопное приложение 1С может периодически опрашивать брокер сообщений (или соответствующий веб-сервис) на наличие новых данных. При обнаружении сообщения, оно будет прочитано и обработано. Для этого в 1С мы используем РегламентныеЗадания. Например, каждые 30 секунд или 1 минуту 1С выполняет запрос к API, который проверяет наличие новых сообщений в очереди.
Концептуальный пример регламентного задания в 1С для опроса:
// В общем модуле, который может быть вызван регламентным заданием:
Процедура ПроверитьНовыеСообщенияИзОблака() Экспорт
// URL нашего облачного шлюза/API для получения сообщений
URLШлюза = "https://api.yourcloudgateway.com/get_messages";
HTTPЗапрос = Новый HTTPЗапрос(URLШлюза);
HTTPСоединение = Новый HTTPСоединение("api.yourcloudgateway.com");
Попытка
HTTPОтвет = HTTPСоединение.Отправить(HTTPЗапрос);
Если HTTPОтвет.КодСостояния = 200 Тогда
СтрокаJSON = HTTPОтвет.ПолучитьТелоКакСтроку();
Если Не ПустаяСтрока(СтрокаJSON) Тогда
// Десериализуем JSON
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(СтрокаJSON);
СписокСообщений = ПрочитатьJSON(ЧтениеJSON);
Для Каждого Сообщение Из СписокСообщений Цикл
// Здесь мы обрабатываем каждое полученное сообщение.
// Например, создаем документ или обновляем статус.
Сообщить("Получено новое сообщение: " + Сообщение.ТипСобытия + " " + Сообщение.ДокументGUID);
// ... Логика создания/обновления данных в 1С ...
КонецЦикла;
Иначе
Сообщить("Нет новых сообщений.");
КонецЕсли;
Иначе
Сообщить("Ошибка при опросе облака: " + HTTPОтвет.КодСостояния);
КонецЕсли;
Исключение
Сообщить("Ошибка соединения или обработки опроса: " + ОписаниеОшибки());
КонецПопытки;
КонецПроцедуры
// Регламентное задание будет настроено на вызов этой процедуры
// с заданной периодичностью (например, каждые 30 секунд).
Мы должны учитывать, что частый опрос может создавать дополнительную нагрузку на сервер и сеть, поэтому важно выбирать оптимальную частоту опроса в зависимости от критичности и объема данных.
Ранее мы упоминали, что для оперативного обмена сообщениями и получения уведомлений обычные облачные хранилища файлов, такие как Яндекс.Диск, Облако Mail.ru, Dropbox или Google Drive, являются менее подходящими решениями. Давайте проанализируем, почему.
Основное назначение этих сервисов — это хранение файлов, их синхронизация и предоставление доступа с различных устройств. Хотя они, безусловно, позволяют обмениваться файлами, их модель работы не оптимизирована для событийного, асинхронного обмена сообщениями в реальном или почти реальном времени. Если мы хотим получать мгновенные уведомления о «новых вызовах» без постоянного и неэффективного опроса изменений в файлах, то файловые хранилища нам не помогут.
Представьте себе сценарий: мобильное приложение создает файл с информацией о «новом вызове» на Яндекс.Диске. Чтобы десктопная 1С узнала об этом, ей придется постоянно (каждые несколько секунд) проверять папку на Яндекс.Диске на наличие новых файлов или изменений в существующих. Такой подход является крайне неэффективным, расточительным по ресурсам (сеть, процессор) и создает ненужную задержку. В отличие от этого, брокеры сообщений и push-уведомления спроектированы именно для мгновенной доставки информации, когда событие происходит, без постоянного активного запроса со стороны получателя.
Таким образом, для нашей задачи, требующей оперативного информирования о новых событиях, наиболее эффективным будет сочетание брокера сообщений (например, RabbitMQ или управляемый сервис очередей) для надежного асинхронного обмена данными, веб-сервисов 1С для публикации и получения данных, а также механизмов уведомлений (например, Firebase Cloud Messaging или прямой опрос очереди через регламентные задания) для оповещения десктопного приложения о новых событиях. Этот комплексный подход обеспечит высокую производительность, надежность и гибкость нашего решения.