gifts2017

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

Опубликовал Петр Базелюк (pbazeliuk) в раздел Обмен - Обмен с другими системами

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

Ссылка на предыдущую статью: "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 компоненты, так как планируется передавать большие объемы данных. Весь инструментарий, который понадобится:

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

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!";
        }       
    }
}

С помощью NuGet console выполняем команду "install-package RabbitMQ.Client". В проекте должны появиться необходимые ссылки на RabbitMQ.Client. Компилируем, и компонента готова. Реализация общего модуля (все компоненты сохранены в конфигурации как бинарные макеты). На первом этапе загружаем внешнюю компоненту, далее возвращаем ее ссылку в метод, который вызвал инициализацию, на втором этапе, если компонента отличается от Неопределено, — вызываем функцию общего модуля ВыполнитьОтправкуВОчередь.

#Область ПрограммныйИнтерфейс

Функция ПолучитьОбъектКласса1CV8Publisher() Экспорт
	
	ПодключитьВнешнююКомпоненту("ОбщийМакет.NETLoader", "NET", ТипВнешнейКомпоненты.Native);
	
	Попытка
		Компонента = Новый("AddIn.NET.NETLoader");
	Исключение
		ТекстСообщения = НСтр("ru = 'Ошибка при подключении компоненты ""AddIn.NET.NETLoader"": %ТекстСообщения%'");
		ТекстСообщения = СтрЗаменить(ТекстСообщения, "%ТекстСообщения%", ОписаниеОшибки());
		ЗаписьЖурналаРегистрации("AddIn.NET.NETLoader", 
						УровеньЖурналаРегистрации.Ошибка, 
							,
							,
							ТекстСообщения,
							);
		Возврат Неопределено;
	КонецПопытки;
	
	КаталогКомпонент = КаталогВременныхФайлов() + Новый УникальныйИдентификатор;
	СоздатьКаталог(КаталогКомпонент);
	ПолучитьОбщийМакет("RabbitMQ").Записать(КаталогКомпонент + "\RabbitMQ.Client.dll");
	ПолучитьОбщийМакет("V8Publisher").Записать(КаталогКомпонент + "\1CV8Publisher.dll");
	
	Попытка		
		Компонента.CreateObject(КаталогКомпонент, "1CV8Publisher", "_1CV8Publisher.V8Publisher", , Истина);
	Исключение
		ТекстОшибки = Компонента.GetLastError();
		Если ПустаяСтрока(ТекстОшибки) Тогда
			ТекстОшибки = ОписаниеОшибки();
		КонецЕсли;
		ТекстСообщения = НСтр("ru = 'Ошибка при вызове метода ""CreateObject"": %ТекстОшибки%'");
		ТекстСообщения = СтрЗаменить(ТекстСообщения, "%ТекстОшибки%", ТекстОшибки);
		ЗаписьЖурналаРегистрации("1CV8Publisher", 
						УровеньЖурналаРегистрации.Ошибка, 
							,
							,
							ТекстСообщения,
							);
		Возврат Неопределено;
	КонецПопытки;
	
	Компонента.HostName = "hostname";
	Компонента.UserName = "admin";
	Компонента.Password = "admin";
	Возврат Компонента;	
КонецФункции // ПолучитьОбъектКласса1CV8Publisher()

Функция ВыполнитьОтправкуДанныхВОчередь(Компонента, Exchange, RoutingKey, Message) Экспорт
	Компонента.Exchange = Exchange;
	Компонента.RoutingKey = RoutingKey;	
	Результат = Компонента.SengMessage(Message);
	Если Результат <> "Data delivered successfully!" Тогда
		ВызватьИсключение Результат; 	
	КонецЕсли;
	Возврат Результат;
КонецФункции // ВыполнитьОтправкуДанныхВОчередь()

#КонецОбласти

Теперь создадим очереди в RabbitMQ (связь систем 1 к 1, для связей 1 к 2 и больше необходимо создать дополнительные очереди, которые будут заполняться с помощью routing):

 Создадим exchanges, в которых укажем routing:

ВыполнитьОтправкуДанныхВОчередь(Компонента, "users", "users.event.create", Message);

Соответственно, после выполнения данной строки кода, в очередь users-create-queue упадут данные из параметра Message. Обратите внимание, нигде не указывается, в какую очередь отправляются данные, а указывается exchange и routing key. Для обмена с двумя системами просто нужно добавить новую очередь, которая предназначена для системы №2, и в exchange добавить тот же routing key, но указать очередь №2. Вот так осуществляется подписка на простые события.

 

Послесловие

Этот подход работает лучше, чем Zato ESB + OData. Время рассудит, станет ли это "серебряной пулей" или простой рабочей лошадкой для специфических задач интеграции.

Если вам помогла статья, благодарность можно выразить денежно.

Статья в личном блоге клац.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Sergei (kauksi) 18.03.16 10:44
Интересно, познавательно, но статья больше для Geektimes - слишком много умных слов которые большинство никогда не слышали. По русски можно: где это 100 миллионов записей и куда этот классный механизм очередей прицепляется?
2. Петр Базелюк (pbazeliuk) 18.03.16 11:31
(1) kauksi, 100 млн. это цены номенклатуры, большинство других расчетов так же содержат сопоставимые объемы. Статья не предназначена для большинства аудитории, больше на развитие. Используя только 1С:Предприятие невозможно добиться необходимой гибкости, отказоустойчивости и ценности для конечного покупателя. Тренд все больше смещается на уменьшение задержек обменов с поставщиками, мобильными системами, а так же произвольным анализом данных в невероятных разрезах. Будущее, в этом плане, пока точно не за 1С:Предприятие, а за небольшими сервисами. У нас плавно идет смещение, что 1С:Предприятие это система где хранится первичная документация, например, подача документации в контролирующие органы идет с помощью других систем.
RomanRomans; cegorach; nixel; kuntashov; starik-2005; +5 Ответить
3. pahalovo (pahalovo) 18.03.16 11:42
А как можно подписаться из 1С на получение сообщений из очереди?
4. Петр Базелюк (pbazeliuk) 18.03.16 11:57
(3) pahalovo,
1С -> Очередь -> 1С. Реализовать прокси(http://infostart.ru/public/333924/) и 1С SOAP\HTTP сервис на принимающей стороне.
1С -> Очередь -> иная система. Воспользоваться примерами http://www.rabbitmq.com/getstarted.html
5. Петр Базелюк (pbazeliuk) 18.03.16 12:34
(3) pahalovo, в принципе могу написать статью, как создать службу которая будет выполнять функции прокси-сервера. Правда на другом ресурсе, так как связь с тематикой 1С:Предприятие минимальная.
6. Вова Вишин (Tahallus) 18.03.16 12:36
7. pahalovo (pahalovo) 18.03.16 13:14
(5) pbazeliuk, напиши, тема интересная. Как то искал готовое решение, которое бы забирало сообщение из очереди и пушило в веб-сервис. Пытался прикрутить для этой цели wso2. Сейчас понимаю, что написать свой адаптер будет проще и надежней.
9. Сергей Филькин (FSerg) 18.03.16 14:05
Спасибо за статью! Очень позновательно.
10. Петр Базелюк (pbazeliuk) 18.03.16 14:22
(8) Serginio, а как отловить события, если не существует соединений на кластере серверов 1С:Предприятия и не запущен ни один сеанс, только висит один единственный Apache?
11. Сергей Смирнов (Serginio) 18.03.16 14:36
(10) Я делал отдельный сервис и через него отправлял и полученные события отправлял на вэб сервис 1С.
Отпрвавлял через пайпы

Кстати многие используют для таких вещей Вэб сервисы. Просто они тяжеловаты по сравнению с NetNamedPipeBinding
12. Сергей Смирнов (Serginio) 18.03.16 15:11
Кстати не пробовал, но так как статические классы остаются после загрузки их можно использовать и в 1С сервисе.
Можно держать регламентное задание которое будет запускать клиента Rabbit крутить вечный цикл и ждать события получать через AutoResetEvent через concurrentqueue
13. Петр Базелюк (pbazeliuk) 18.03.16 15:29
(12) Serginio, с регламентными заданиями так же проблем достаточно, да и лицензия расходуется и обработка в один поток всего.
14. Сергей Смирнов (Serginio) 18.03.16 15:37
(13) C# потоков ты можешь использовать сколько угодно. Кстати откуда данные, что регламентные задания лицензии используют?
Кстати здесь http://infostart.ru/public/466052/ есть пример запуска асинхронных запросов и ожидания выполнения.
лист=Врап.СоздатьОбъект("System.Collections.Generic.List`1[System.Threading.Tasks.Task]");
    Для сч=1 по 10 Цикл
           Задача=Клиент.GetStringAsync(СокрЛП(сч));
           лист.Add(задача); 
       КонецЦикла;

      Task=Врап.ПолучитьТип("System.Threading.Tasks.Task");


      массив=лист.ToArray(); 


      Task.WaitAll(массив);


      Для каждого задача из лист Цикл 
         Сообщить(задача.Result); 
      КонецЦикла


...Показать Скрыть
15. Петр Базелюк (pbazeliuk) 18.03.16 18:15
(14) Serginio, плюсом отметился, но с поддержкой замучаетесь, да и код понятен тому кто понимает в с# и 1С:Предприятие. Как по мне не зачем тащить внутренности c# в 1С:Предприятие, если мы теряем полезные фичи языка еще и сопровождаемость кода сильно усложняется.
16. Андрей Кейних (Bronislav) 18.03.16 18:46
Ого, статья про мой любимый rabbitmq :)
Практика показала, что лучше отказаться от всяческих фоновых заданий и смотреть в сторону событийной архитектуры интеграции. Принимать сообщения через службу-адаптер, которая подписывается на exchange с типом topic, и пересылает сообщения в соответствующие методы http-сервиса 1С. А отправлять сообщения через простенькую внешнюю компоненту. Таким образом получается асинхронный обмен, который происходит практически синхронно.
А уж чего стоит его плагин federation, который позволяет создать распределенную филиальную сеть и пробрасывать очереди\exchange из центра в филиалы и наоборот.
В работе кролик ведет себя крайне стабильно, за пару лет использования не могу вспомнить его падений.
17. Сергей Смирнов (Serginio) 18.03.16 19:34
(15) Спасибо. Я как раз эту разработку делал для использования Вэб сервисов неподдерживаемых 1С с кучей классов. Отдельно писать очень муторно. А здесь создал сборку, подключил ссылку на сервис скомпилировал и все впорядке. Кроме того сделал поддержку событий и жизнь стала еще легче. Кроме того никто не запрещает сделать свою сборку как у тебя, только использовать через Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент Просто в отличии от NETLoader можно использовать COM объекты. В данной разработке все .Net классы оборачиваются через Com объекты.
И можно например использовать AutoResetEvent для сигнализации о получении сообщения итд. Больше возможностей.

А зарегистрировать можно только на сервере и использовать любые нетовские сборки.
18. Андрей Кейних (Bronislav) 19.03.16 06:46
Я правильно понимаю, что проект который заморозили на zato, в итоге запустили на rabbitmq?
Можно подробнее развернуть про этот проект? Сколько систем участвовало в интеграции, кластеризовали ли кролика, использовали ли in-memory, плагин federation, shovel? Маршрутизацию настраивали руками через вебморду или использовали топики и ключи маршрутизации?
Рад видеть, что кто-то еще использует rabbitmq :)
19. Петр Базелюк (pbazeliuk) 19.03.16 11:57
(18) Bronislav, проект в замороженном состоянии, но уже практически его похоронили.
Проект на RabbitMQ новый и перспективный, он похож на первый проект но с существенным отличием - система с которой будет происходить интеграция будет разработана под наши требования, а не взята в аренду (в которой изменить по сути было что-то невозможно). Это, можно сказать, проба пера первые практические результаты будут примерно в начале мая. Проект можно грубо назвать - облачная система продаж.
По поводу настроек: и через веб-интерфейс и с помощью скриптов.
20. Sergey Andreev (starik-2005) 19.03.16 12:15
(13) pbazeliuk, ну не совсем так. Можно и в 1С сколько угодно потоков запустить с помощью фоновых заданий. В принципе, тут статья про многопоточность, а тут про реализацию мьютексов, если они необходимы (а в таких системах вполне могут пригодиться)..

По поводу того, что 1С - это не более, чем система для хранения первичных документов и ведения бухгалтерского учета - можно согласиться. Я считаю даже опасным на данном этапе развития экосистемы 1С попытки организовать на ней работу со всем и вся, хотя, конечно, она кое-что может. Но когда SLA информационной системы - это доли секунды, то 1С в этом месте делать совершенно нечего. Она или упадет, или зависнет, или еще что-то с ней случится. И тут либо помогают огромные вложения в технологический парк (которые в действительности помогают мало, т.к. 1С все-равно зависает и падает), либо такие же вложения в создание отказоустойчивых систем вне 1С, которым хватит имеющихся ресурсов (которые зависают и падают куда реже, и если это происходит, то по крайней мере есть возможность локализовать и устранить проблему)..
21. Sergey Andreev (starik-2005) 19.03.16 12:18
ЗЫ: Ну и конечно Win Only позиционирование статьи меня радует мало, но за понимание того, что на 1С свет клином не сошелся, однозначный плюс.
22. Роман Цованян (pfihr) 20.03.16 11:34
Про линукс версию 1С для промышленной эксплуатации думать рановато (и под виндой то еще вагон проблем), так что .Net здесь очень в тему.
23. Sergey Andreev (starik-2005) 20.03.16 15:08
(22) pfihr, а какие конкретно проблемы под Linux?
24. Евгений Матыцин (matytsin_new) 21.03.16 10:03
Делал подобное на MSMQ. Передавались сильно связные данные (более поздние сообщения не имеют смысла без более ранних). Возникла проблема, что делать серверу MQ если клиент не забирает данные из очереди. Очередь быстро растет, а очистить ее нельзя, поскольку 1с не сможет восстановить поток событий для очереди по требованию.
Это хорошее решение, когда передаются данные, для которых важно только текущее значение (например баланс клиента). Если же важна история, все сразу становится сложнее.
25. Евгений Ванжула (minimajack) 21.03.16 10:16
(24) matytsin_new, зачем очищать очередь? Очередь на то и существует что бы получить все сообщения. Если очередь растет - проблема не в очереди, а в 1С которая не забирает данные.
26. Сергей Смирнов (Serginio) 21.03.16 16:51
Если, что то вот еще один вариант обмена данными http://infostart.ru/public/402038/
27. Петр Базелюк (pbazeliuk) 22.03.16 01:47
(26) Serginio, тысяча чертей, лень читать и разбираться в простыне кода :) хоть бы описание было: что? куда? и зачем?
28. Петр Базелюк (pbazeliuk) 22.03.16 02:01
(26) Serginio, немного разобрался, но все равно не могу понять в чем преимущество? Да EF и LINQ клевая штука, но не сильно производительная (в книге Metaprogramming in .NET рассматривают этот вопрос).
29. Сергей Смирнов (Serginio) 22.03.16 07:34
Нормально там с производительностью, уж значительно быстрее чем через посредника. Смысл в том, что ты можешь тянуть данные напрямую, без посредника. Я помню сам из Штатов так прайсы миллионные скачивал, правда из MySQL. Но суть та же.
31. Сергей Д (dddxddd) 22.03.16 08:44
ИМХО статья названа неправильно.
Про пороблемы OData ровно одно предложение и то оно ниочем. Думаю правильней бы назвать "Как надо использовать -кролика- RabbitMQ" или "КролеГ работает лучше, чем Zato ESB + OData"
Без обид, просто про проблемы реализации OData на платформе, о версии ее реализации как и о версии платформы в статье действительно нет ни слова.
32. Евгений Ванжула (minimajack) 22.03.16 08:58
(28) pbazeliuk, мне интересно как реализован слушатель...через регламентные задания?
33. Сергей Смирнов (Serginio) 22.03.16 10:16
(31) У ODATA http://infostart.ru/public/403524/ по сравнению с SQL огромное количество ограничений.
Правда при использовании MS SQL настраивать MS SQL тоже нужно
https://technet.microsoft.com/ru-ru/library/ms175483(v=sql.105).aspx

Кроме того можно использовать HTTP и WEB сервисы
(32) См. 17
34. Петр Базелюк (pbazeliuk) 22.03.16 10:53
(32) minimajack, Win-служба пинает 1С HTTP-сервис, ждет пока 1С даст ответ что все отлично и сообщение можно удалять из очереди.
35. Петр Базелюк (pbazeliuk) 22.03.16 11:12
(31) dddxddd, описал в статье проблемы OData которые были важны, в первую очередь, для нас. Да, возможно, не описал качественных показателей скорости получения данных из OData и Native компоненты. Разница в скорости примерно в 1000 раз. Так же OData не дает возможности получить больших массивов данных это при наших 192ГБ оперативной памяти и 40 ядрах процессора... службы 1с просто напросто падают.
36. Алексей Лустин (lustin) 22.03.16 12:28
(0) круто !!!

На данный момент при обучении и внедрении я использую первый кейс.

Я вставляю событие ПриДобавленииСтрокиЧекаПродажи() -> ОтправитьВОчередь("retail.api.check.add.line", _GUIDТовара, _CodeТовара, _DescrТовара)
В центре стоит подписчик которые рисует онлайн отчет с автообновлением под названием "Онлайн спрос на товар"
Отчет выведен на большой экран и показывает текущий интерес к товару.

Руководителям отделов продаж очень нравится.

Таким вот решением достигается такое, что данные по событиям с кассовых мест получаются в центре не более чем через 15 секунд

2 плагина необходимы для этого

https://www.rabbitmq.com/shovel.html
https://www.rabbitmq.com/federation.html

(0) За ссылку на наше 8 часовое веселье спасибо. Применительно к ZatoESB я со сцены Инфостарта передавал вам привет, за наводку на неё. Передаю и тут ;-)
pbazeliuk; +1 Ответить
38. Сэр Артур (kite2) 22.03.16 16:17
Первая причина это ты, а вторая все твои мечты... :)
39. Сергей Смирнов (Serginio) 22.03.16 21:07
(35) Кстати какой формат использовали? XML,JSON?
Использовали ли при запросах gzip?
40. Петр Базелюк (pbazeliuk) 22.03.16 21:57
(39) Serginio, формат сообщения JSON, который конвертируется в байты. Если понадобится сможем использовать Deflate.
41. Сергей Смирнов (Serginio) 22.03.16 22:32
(40) Я про ODATA какой формат использовали?
42. Сергей Смирнов (Serginio) 22.03.16 22:35
Кстати, а ProtoBuf не хотите использоват? https://habrahabr.ru/post/119503/
43. Петр Базелюк (pbazeliuk) 22.03.16 23:04
(42) Serginio, зачем? данные не предназначены для систем, которые работают на .Net. .Net у нас прослойка для отправки сообщений в очередь из 1С и получении сообщений из очереди в 1С.

(41) Serginio, частично XML, когда появилась поддержка JSON начали использовать его.
minimajack; +1 Ответить 1
44. Евгений Ванжула (minimajack) 22.03.16 23:08
(42) Serginio, нахрена козе боян? протобуф из другой оперы ...
45. Сергей Смирнов (Serginio) 23.03.16 00:31
(44) Из той. Он быстрее и компактнее, классы .Net тоже могут прослойкой.
(43) И какова разница использования Odata с JSON и XML?
46. Евгений Ванжула (minimajack) 23.03.16 08:12
(45) Serginio,
1. Лишняя прослойка
2. Скорость будет медленнее нативной сериализации
3. Нет готовых библиотек для 1С
4. Нет сложных классов для передачи (только в таком кейсе протобуф выгоден)

вывод: лишние костыли в инородной системе

зы быстрее и компактнее не про 1С. Сэкономленные 5% трафика - смешно по сравнению с рисками и дополнительными косяками.
ззы от пиара .Net уже тошнит ей богу - такое в ентерпрайс пустят только гики.
47. Антон Бордачев (iTony73) 23.03.16 10:24
По какой причине, не использовался продукт Axelot ESB? На текущий день, это коробочный продукт, непосредственно под эти цели, включил - работает; Из за того что он новый и появился недавно?
48. Сергей Смирнов (Serginio) 23.03.16 10:24
(46) Нет не будет. Можно использовать любые .Net библиотеки
Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
Использование классов .Net в 1С для новичков

Еще раз с помощью .Net классов можно решать любые задачи без использования ВК.
Другое дело, что самым быстрым будет прямой доступ через SQL. Можно использовать ADO.
Кстати данная разработка тоже построена на .Net. Тебя это почему то не коробит.
49. Петр Базелюк (pbazeliuk) 23.03.16 10:45
(47) iTony73, информационный поток очень большой и за всем сложно уследить. Спасибо за ссылку, ознакомлюсь.
50. Евгений Ванжула (minimajack) 23.03.16 11:05
(48) Serginio, меня интересует не реализация - а подход.
Использовать MQ - хорошо, OData - нормально(нет транзакционности из коробки), ADO - бред, EF - бред.
зы имхо, объяснять почему что то хорошо, что то нет - не хочется; но кровавый энтерпрайз диктует свои требования.
51. Сергей Смирнов (Serginio) 23.03.16 15:01
(50) Вот и пришли, что нетовский клиент RabbitMQ это хорошо, а другой нетовский класс это плохо. Где логика?
Про ADO расскажу такую исторю. Нужно мне было загружать миллионные прайсы в регистр сведений. Загружать через набор записей очень долго, так как удаляются все записи, а потом записывается опять полный набор. По одной записи обновлять, удаляь и добавлять тоже накладно. Но вот загрузить из текстового файла булками в темповую таблицу и использовать Merge для объединения данных решило проблему. Там где было десятки минут, стало пару минут. По твоему это бред. По мнению моей конторы это огромное облегчение труда и удобства для клиентов.
52. Евгений Ванжула (minimajack) 23.03.16 15:25
(51) Serginio, MQ - message queue - по русски очередь сообщений. Использовать очереди это хорошо, то что используется .Net - мне не нравится.
Нужно мне было загружать миллионные прайсы в регистр сведений
- ну что тут сказать...тут вариантов тьма. Важен кейс использования этих данных - по видимому проблема в архитектуре приложения.
53. Сергей Смирнов (Serginio) 23.03.16 15:35
(52) minimajack,
Проблема в том, что еще клиенты просят прайсы с наилучшими ценами. А количество позиций по десякам прайсов было по 100 миллионов. Там еще использовалась конструкция WITH TIES для отбора по цене и остаткам на складе. Все делалось для клиентов. Но это было быстро и удобно. При этом работали и вэб сервисы, как к нам так и от нас.
В чем проблемы в архитектуре?
54. Евгений Ванжула (minimajack) 23.03.16 15:41
(53) Serginio, надеяться на 1С8 загружая стомиллионные прайсы и ожидая отклик в несколько минут
55. Сергей Смирнов (Serginio) 23.03.16 15:46
(54) minimajack, нет проблем до сих пор. Так, как запись все в обход 1С. А вот что касается поиска и прочее 1С прекрасно работает уже лет 7. Что я делаю не так? Кстати про WITH TIES
http://www.forum.mista.ru/topic.php?id=751931&page=2#163
56. Андрей Овсянкин (Evil Beaver) 29.03.16 14:53
(0) из статьи не уловил - куда ушел OData из связки с 1С? 1С каким механизмом вызывается со стороны очереди? Или она только кладет что-то в Rabbit и извне не вызывается?
57. Евгений Ванжула (minimajack) 29.03.16 15:02
(56) Evil Beaver,
Win-служба пинает 1С HTTP-сервис, ждет пока 1С даст ответ что все отлично и сообщение можно удалять из очереди.

костыль в общем)
58. Алекс Кулаков (AKulakoff) 01.04.16 09:41
Добрый, а почему выбрали именно RabbitMQ, чем он хорош этот менеджер очередей ? что кроме организации очереди может реализовать. Возможно ли трансформация передаваемого пакета.
Не рассматривали IBM WebSphere MQ, правда стоимость его не совсем привлекательная.
59. Петр Базелюк (pbazeliuk) 08.04.16 10:44
(58) AKulakoff, добрый день, выбрали потому, что стоимость и порог входа минимальный, а так же делаем точки соприкосновений различных языков (php, python, c#, 1C, JavaScript). Это дает возможность использовать другие технологии, с которыми в 1С есть проблемы, например: гарантия доставки сообщений, dash boards, мобильные приложения, версионирование объектов, для поиска - ElasticSearch и т. п.
В трансформации пакета, не вижу надобности. Все данные ходят в формате JSON, в случае если другой системе понадобятся данные она подпишется на необходимый обмен со своей анонимной очередью.

60. Петр Базелюк (pbazeliuk) 08.04.16 10:51
(58) AKulakoff, отличная скорость доставки сообщения из 1С:Предприятие (с помощью Native компоненты) в RabbitMQ занимает это дело около 5-7 мс. В принципе можно посмотреть на пульс обмена и понять, когда происходят пики нагрузки.
62. Петр Базелюк (pbazeliuk) 10.04.16 22:18
(18) Bronislav, вот как-то так выглядит схема использования у нас
63. Андрей Кейних (Bronislav) 11.04.16 05:26
(62) pbazeliuk
Отлично :)
Exchange с типом топик используете?
Насколько понял из схемы, 1С ничего не знает о мобильных и веб приложениях и они как постоянные подписчики работают?
64. Петр Базелюк (pbazeliuk) 11.04.16 08:44
(63) Bronislav, не постоянные, если кто-то подписывается он создает свою анонимную очередь и добавляет bind в exchange (какие именно события отлавливать), при отписке очередь автоматически уничтожается. По похожем принципу работает RPC. Да exchange с типом topic.
В итоге руками только созданы 3 объекта - rpc queue, exchange queue и log queue, все остальное динамическое.
65. Андрей Овсянкин (Evil Beaver) 11.04.16 15:09
(62) pbazeliuk, а чем такую чудесную диаграмму рисовали?
66. Петр Базелюк (pbazeliuk) 11.04.16 15:17
(65) Evil Beaver, да у меня жена профессиональный дизайнер, в декрете скучно ей, подрисовывает (Adobe illustrator) :)
JohnyDeath; Evil Beaver; +2 Ответить
67. Алекс Кулаков (AKulakoff) 14.04.16 18:21
(59) Трансформация обычно нужна, когда один объект летит в несколько баз и для каждой базы требуется свой пакет.
Так было в моем случае, но решение было на IBM WebSphere MQ, правда порог входа в нее совсем не бюджетный ...
А есть статистика сколько пакетов проходит за определенный период (час, день)
68. Петр Базелюк (pbazeliuk) 14.04.16 22:16
(67) AKulakoff, около 10 тыс. сообщений в час, но это пока тестовый режим. Дальше будет видно.
69. Алексей Лустин (lustin) 21.04.16 09:10
(58) AKulakoff, ВебСфера очень дорого... прям запредельно... в том числе по стоимости владения, а не только по лицензиям. Как и другие платформы интеграции за авторством Java программистов.

лучшей реализации AMQP кроме RabbitMQ для production сейчас не найти.
70. Алексей Лустин (lustin) 21.04.16 09:21
(68) кстати насчет Zato + OData. Я как то говорил, что проблема не в этой связке как таковой - Zato удобная для понимания концепции ESB. Но Zato заточено под EDA - https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B9%D0%BD%D0­%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2­%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%8­2%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0

C точки зрения EDA OData протокол реализациия в 1С слишком избыточна - 1С-ные объекты "большие". Поэтому ZatoESB у нас на методических проектах используется только как сервис создания API и сервис интеграции одного API в другое.
71. Евгений Ванжула (minimajack) 21.04.16 09:22
(69) lustin, эээээээ!! А как же http://activemq.apache.org/ ?
добавляем везде слово ИМХО
для интеграции с 1С практически все равно какая MQ...1С просто не загрузит шину ИМХО =))
72. Алексей Лустин (lustin) 22.04.16 13:08
(71) minimajack, тут такое дело. Я бы добавил IMHO... Но мне жалко тех, кто потеряет время идя по граблям, по которым уже все ходили и не раз.

Эксперименты с очередями в 1С начались очень давно:

https://code.google.com/archive/p/one-c-connectors/

выводы следующие:

* MQ для 1С может быть любой в порядке эксперимента
* для реального продуктива наилучшие результаты показала RabbiMQ за счет возможности строить "федеративные" "topic" ориентированные кластеры ядра интеграции.
* напомню что в облачном провайдере OpenStack AMQP реализация сделана именно на RabbitMQ за счет производительности
* MQ для EDA недостаточно, надо именно AMQP, поэтому из нашего списка выбывает также MSMQ и ее попытки реинкарнации со стороны Microsoft, на базе SQL сервера

На всякий случай перенес на GitHub старый проект с Code.Google.Com, обратите внимание на 4 статьи за авторством Андрея Межова - очень помогает осознавать.

https://github.com/allustin/one-c-connectors
Примеры адаптеров по состоянию "на тогда" - https://github.com/allustin/one-c-connectors/tree/master/Projects/MOMAdapters/MOMAdapters
Можете использовать для экспериментов.

Теперь что касается "имхо"... Я обычно говорю следующее

* c ActiveMQ я "пережил боль" в далеком 2010 году и врагу не пожелаю эту веселуху.
* с точки зрения консалтинга я рекомендую именно RabbitMQ
* я не рекомендую использование для Enterprise шин типа BizTalk, Websphere но с этим приходится мириться в силу политических особенностей каждой конторы

на текущий момент наиболее успешные проекты построены на:

* ZatoESB + RAbbitMQ
* muleESB + RabbitMQ

средней степени успешности проекты построены на

* WSO2 + RabbitMQ

Но это НЕ моё скромное мнение, в этой рекомендации заложен огромный опыт по проектам интеграции в стиле EDA.
Но вы как обычно можете делать то что считаете правильным Вы на основе своего опыта.

Мы в нашей команде уже использовали много шин и очередей. https://bitbucket.org/alexey_yakimovich/
Насколько я знаю Алексей сейчас будет в ближайшие три месяца "вертеть" Oracle ESB - думаю результаты он опубликует ближе к осени.

А так как Oracle Advanced Queue построена по примеру Microsoft "на тригерах" внутри Oracle DBMS, то первое что приходится прикручивать к этому делу - https://github.com/pmq/rabbitmq-oracle-stored-procedures

И дальше адаптировать...
dm2010; FSerg; Bronislav; Evil Beaver; +4 Ответить 2
73. Алексей Лустин (lustin) 18.06.16 15:52
(0) еще раз пересмотрел название очередей. Пётр - вопрос, а вы серьёзно подходили к разработке routing topologies ? Если в статье указан пример - то ладно, а если реальные наименование, то они "слишком абстрактные".
74. Петр Базелюк (pbazeliuk) 18.06.16 17:12
(73) lustin, на самом деле все по другому.
Вот это реальная схема получения информации из 1С
Оповещения о других событиях 1С идут в Exchange (1c.events), по определенным routing keys. На оповещения подписываются анонимные очереди.

Схема работы примерно такая: запускается сторонний сервис, получает полную информацию по схеме RPC, паралельно создает анонимную очередь и подписывается на определенные события (1c.events). Когда сервис отключается, анонимная очередь уничтожается. Пакеты о событиях нумеруются, что бы сервис понимал что произошел сбой сети и снова получил полную информацию по RPC.
75. Максим Кузнецов (Makushimo) 07.07.16 11:54
Круто. но нифига не понятно.
гугел, я к тебе -))
76. Петр Базелюк (pbazeliuk) 29.07.16 16:56
(72) lustin,
Мы в нашей команде уже использовали много шин и очередей. https://bitbucket.org/alexey_yakimovich/


Просмотрел этот проект, на сколько понимаю, проба пера? Потому, что для больших нагрузок (несколько тысяч сообщений в секунду) и больших трансферов (больше 500MB) не предназначен. Хотел спросить может есть у вас Native компонента для 1С для отправки? У себя пока используем hosting CLR, но по производительности при высокой частоте сообщений появляются проблемы.
77. Сергей Смирнов (Serginio) 29.07.16 21:21
Тебе стоит посмотреть в сторону асинхронного выполнения методов
78. Петр Базелюк (pbazeliuk) 29.07.16 21:26
(77) Serginio, сервис, для RPC, работает асинхронно, с ним все отлично. Проблема больше в компоненте 1С которая передает данные, проблема не в размере передачи данных, а в частоте их передачи.
79. Сергей Смирнов (Serginio) 29.07.16 21:52
(78) Я говорю про асинхронную передачу из 1С
.Net в 1С. Асинхронные HTTP запросы, отправка Post нескольких файлов multipart/form-data, сжатие трафика с использованием gzip, deflate, удобный парсинг сайтов и т.д.

Там есть пример
 Выполнитель=Врап.ПолучитьАсинхронныйВыполнитель();
    ДобавитьОбработчик Выполнитель.ПриОкончанииВыполненияЗадачи, ПриОкончанииВыполнения;
    
    ВыполненоЗадач=0;
    МассивОтветов=новый массив;
    
    stopWatch = Врап.СоздатьОбъект("System.Diagnostics.Stopwatch");
    stopWatch.Start();
            Для сч=1 По 100 Цикл
            // Получили задачу, которая выполняется в другом потоке
            // Обычно запрос отправляется быстро, а результат получает по событию.
            // При этом потоки не простаивают для ожидания результата
                Задача=Клиент.GetStringAsync(СокрЛП(сч));
           // если нужен результат то дожидаемся
           // и вызываем ПриОкончанииВыполнения
                 Выполнитель.Выполнить(задача,ТекущаяДата());

            
             КонецЦикла; 
             
КонецПроцедуры
...Показать Скрыть



И сама процедура

Процедура ПриОкончанииВыполнения(Задача,ДанныеКЗадаче)

    // Обязательно нужно отлавливать ошибку в 1С
    // Иначе она передается в .Net где обрабатывается там
    Попытка
Так как задача может завершиться с ошибкой
Мы должны проверить, и если ошибка нужно предпринять какие то действия
        Если (Задача.IsFaulted) Тогда  // Ошибка выполнения

            Сообщить("Ошибка "+Врап.ВСтроку(Задача.Exception));
            Сообщить("Данные к задаче "+Врап.ВСтроку(ДанныеКЗадаче));

        иначе
            Сообщить("=====Выполнена задача ====");
            Сообщить("Данные к задаче "+Врап.ВСтроку(ДанныеКЗадаче));
            Сообщить(Врап.ВСтроку(Задача.Result));


        КонецЕсли;

    Исключение
        Сообщить("Ошибка в процедуре");
        Сообщить(ОписаниеОшибки());
    КонецПопытки

КонецПроцедуры
...Показать Скрыть
80. Сергей Смирнов (Serginio) 29.07.16 22:00
Наверняка у RabbitMQ.Client есть асинхронные методы
81. Петр Базелюк (pbazeliuk) 29.07.16 22:01
(79) Serginio, при использовании HTTP больших размеров падает RabbitMQ. Для больших данных только TCP.
82. Петр Базелюк (pbazeliuk) 29.07.16 22:02
83. Сергей Смирнов (Serginio) 29.07.16 22:16
Ну можно и самому вызов в Task завернуть. Главное, что бы 1С не ждала результата. Странно, что RabbitMQ.Client не используют. Асинхронные методы уже стандарт в .Net
84. Сергей Смирнов (Serginio) 29.07.16 22:20
Второй вариант это 1С кладет данные в очередь, а уже отправкой занимается класс на C#. Скорость вызова на моей кроссплатформенной компоненте порядка 40 000 вызовов в секунду.
denis.v.petroff; +1 Ответить
85. Сергей Смирнов (Serginio) 29.07.16 23:50
Но проще запускать Task.Run а внутри планировщик сам создаст очередь
86. Александр Голошумов (Mambetin) 01.08.16 14:03
Ну вот почему то про очереди все славно поговорили.... а про трансформацию ни слова.
А это самый геморрой.

87. Евгений Сосна (pumbaE) 01.08.16 15:04
(86) Mambetin, а что есть какая-то волшебная таблетка от геморроя при трансформации? Как не крути, а трансформация всегда будет геморроем и тут без разницы - будет это в 1с, в какой-нибудь esb шине или еще где-то.
88. Александр Голошумов (Mambetin) 02.08.16 10:29
(87) pumbaE, так вот и интересно кто в каком месте подорожник прикладывает. в 1С или в очередях колдуют
89. Петр Базелюк (pbazeliuk) 02.08.16 11:33
(88) Mambetin, на стороне 1С конвертируешь объект в json (можно даже сделать универсальный конвертор), а далее те кому он нужен (внешние системы) пусть с ним и разбираются.
90. Александр Голошумов (Mambetin) 02.08.16 13:41
(89) pbazeliuk, в каноническую универсальную структуру объекта ?
91. Петр Базелюк (pbazeliuk) 02.08.16 14:11
(90) Mambetin, если с метаданными умеешь работать, можно даже сделать документацию API на выходе. Можно сделать форму, какие поля будут выгружаться/загружаться и от накликаного автоматически будет формироваться все остальное (Документация + API).
92. Алексей Лустин (lustin) 12.09.16 13:23
(76) pbazeliuk, ох ты... а я пропустил это сообщение

На bitbucket - проект просто обучающий, в рамках понимания тех кто только начинает.

есть такое https://xdd.silverbulleters.org/t/nemnogo-novostej-pro-integracziyu/505/1 - если про NativeAPI, там BDD, CMake и кроссплатформенность. Сейчас в пилотировании.



собственно это то что мы активно делаем сейчас уже как 3 месяца... Еще и mqtt протокол.
93. Петр Базелюк (pbazeliuk) 12.09.16 15:57
(92) lustin, было бы интересно почитать про возможности и концепцию работы в понимании вашей команды.

Со своей стороны, планирую в недалеком времени первичные наработки выложить (те, что вот, от которых будем отказываться в пользу более мощных и универсальных подходов).
Если быть более точным, то вот это: Hosting CLR + Win сервис, ну и базовый код к нему. Это бесплатно, не сильно удобно и с некоторой стороны тяжело в разработке. Так же расписать некоторые нюансы работы с кроликом.

А вот следующий за ним конструктор, библиотека Native API, а так же библиотеки проверки "1С объектов" платно и дорого. Как говорится не только ж события слать, а и создавать эти же "1С объекты".
95. Петр Базелюк (pbazeliuk) 12.09.16 20:57
(94) Serginio, от .NET полностью не собираюсь отказываться. По сути уже целый год прорабатываю различные схемы интеграции и построение сложных систем. Понимаешь есть понятия, как паттерны проектирования, расширения объектов, разграничения ответственности, DI и т. п.

Мне, вот чесно, сложно представить как поддерживать такой код как у тебя, подход возможно стоит внимания, но в плане сопровождаемости он ужасен. Кроссплатформенность под вопросом (под .NET Core нет еще много библиотек, того же SignalR), а поднимать разные слои для взаимодействия простых объектов - лишние затраты программистов и администраторов. Может конечно для небольших внедрений он идеален, но моя цель большие предприятия с большим зоопарком систем и гигантской нагрузкой онлайн.
96. Сергей Смирнов (Serginio) 12.09.16 21:18
(95) SignalR выйдет в 4 кватале либо в первом 2017
https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/

https://github.com/aspnet/Home/wiki/Roadmap

Что касается Hosting CLR + Win сервис то он значительно менее функционален по сравнению с новый COMОбъект("NetObjectToIDispatch45");

Так как поддерживается почти все классы .Net, а внутри используют те же механизмы COM.
Единственно, что нужно регистрировать одну библиотеку. Но все остальные сборки вызываются без регистрации.
Другое дело, что зная ClassID можно создавать IDispatch и без регистрации

Для .Net Core на днях выложу аналог .NET(C#) для 1С. Динамическая компиляция класса обертки для использования .Net событий в 1С через ДобавитьОбработчик или ОбработкаВнешнегоСобытия

А вот, что касается Native API то нужно как то влиять на 1С, что бы они расширили возможности ВК.
Так они наконец дали возможность передавать в параметрах ДвоичныеДанные. Только все это медленно
97. Сергей Смирнов (Serginio) 12.09.16 22:25
Да кстати COM немного быстрее Native API