Каталог решений - 7 причин, почему интеграцию необходимо строить на очередях. Практика RabbitMQ. Отказ от Zato ESB и OData в 1С

Ссылка на предыдущую статью: «7 причин, почему интеграция стала приятной. Не упускайте ряд потрясающих возможностей»

Практические минусы Open Data Protocol

В 1С Предприятие 8.3.5.1068 появилась поддержка автоматического REST-сервиса. Теперь платформа может автоматически формировать REST интерфейс для всего прикладного решения.

Это был глоток свежего воздуха, все данные как на ладони — бери и получай. Конечно, в скором времени появились простые и небольшие сервисы, и работали они стабильно, как часы. Соответственно гений инженерной мысли думает: вот она, «серебряная пуля». Что ж, в порыве эйфории один глобальный проект решено было выполнить, используя: Zato ESB (что же это?) и использовать REST интерфейс OData «1С:Предприятие 8» для обмена между двумя большими системами.

Проблемы, связанные с Open Data Protocol

Для реализации проекта на стороне Zato ESB была нанята команда программистов питонщиков. Основной задачей команды было брать данные из «1С:Предприятие 8» по протоколу OData, а также получать данные при помощи фоновых заданий «1С:Предприятие 8», которые, в свою очередь, передавали изменения данных, необходимых для сторонней системы. На этапе технического задания все выглядело прозрачно, но во время реализации возникли проблемы:

• работа с большими таблицами (некоторые таблицы имели более 100 млн. записей). Получить срез данных было очень проблематично, что часто вызывало падение всех служб 1С;
• получение данных в несколько потоков. Соединения, бывало, часто зависали, и лицензии заканчивались без видимой на то причины, спасал только рестарт службы «1С:Предприятие 8». Забавно было видеть несколько тысяч соединений, которые нельзя удалить;
• танцы с бубнами и велосипедами, чтобы гарантировать доставку сообщений;
• так как обмен работал в две стороны, возникла проблема в контроле логики и верности создания данных в «1С:Предприятие 8»;
• изменение бизнес-процесса в одной системе приводило к необходимости внесения изменений в Zato ESB — в итоге получилась очень большая связность;
• команда питонщиков, по сути, реализовывала буферные копии функционала 1С конфигурации — налицо дублирование кода;
• ребятам питонщикам пришлось учить платформу «1С:Предприятие 8», чтобы понимать, как с этим работать;
• ошибки в самом протоколе OData, что заставляло нас использовать только вышедшие обновления платформы «1С:Предприятие 8» с новой порцией ошибок, уже не связанных с OData.

Проблемы, связанные с Zato ESB

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

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

7 причин, почему интеграцию необходимо строить на очередях

На данном этапе были переосмыслены все ошибки, было принято решение интеграцию строить на очередях, пока видны только одни плюсы, недостатки незаметны:

1. используя очереди RabbitMQ, мы не ограничиваем себя одним языком программирования. Мы можем использовать, в большинстве случаев, родные языки систем, которые интегрируются, для отправки и приема сообщений;
2. для гарантии доставки нам не нужно доставать бубны и велосипеды, если сообщение не может быть положено в очередь, то и транзакция будет безболезненно отменена;
3. интеграция одной системы к многим и наоборот выполняется одной-единственной настройкой роутинга в RabbitMQ;
4. простота формата сообщений, это бинарные данные — мы используем JSON, который переводится в бинарный формат;
5. при высокой нагрузке, на довольно слабом виртуальном сервере, в очередь были доставлены все сообщения;
6. каждый элемент системы не связан с другими элементами другой системы и бизнес-логика не дублируется, контроль целостности данных проверяется в едином месте в той системе, для которой эти данные предназначены;
7. множество типов очередей, даже такие, что позволяют выполнять remote procedure call, но нужно стараться, чтобы системы были минимально связаны, бизнес-логика в «1С:Предприятие 8», а рабочие места, например, это мобильное приложение или веб-сайт.

Передача сообщения из  «1С:Предприятие 8» в RabbitMQ

Для реализации этого механизма было принято решение отказаться от веб-сервиса 1С в пользу NativeAPI компоненты, так как планируется передавать большие объемы данных. Весь инструментарий, который понадобится:

• Использование .NET сборок в 1С 8.2, 8.3 без установки и без регистрации в реестре. Это нам позволит загрузить произвольный c# класс, который будет принимать JSON строку и отправлять в очередь;
• Интеграция корпоративных приложений на платформе 1С (как это было). Полезно для общего развития.

Исходный код, компоненты:

using System;
using System.Text;
using RabbitMQ.Client;

namespace _1CV8Publisher
{
    public class V8Publisher
    {
        public string UserName { get; set; }
        public string Password { get; set; }
        public string HostName { get; set; }  

        public string Exchange { get; set; }
        public string RoutingKey { get; set; }

        public string SengMessage(string message)
        {
            try
            {
                var factory = new ConnectionFactory()
                {
                    HostName = HostName,
                    UserName = UserName,
                    Password = Password
                };
                using (var connection = factory.CreateConnection())
                {
                    using (var channel = connection.CreateModel())
                    {
                        var body = Encoding.UTF8.GetBytes(message);
                        channel.BasicPublish(exchange: Exchange, 
                                            routingKey: RoutingKey,
                                            basicProperties: null,
                                            body: body);
                    }
                }
            }
            catch (Exception e)
            {
                return e.ToString();
            }
           
            return "Data successfully delivered!";
        }       
    }
}