Ссылка на предыдущую статью: «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 причин, почему интеграцию необходимо строить на очередях
На данном этапе были переосмыслены все ошибки, было принято решение интеграцию строить на очередях, пока видны только одни плюсы, недостатки незаметны:
- используя очереди RabbitMQ, мы не ограничиваем себя одним языком программирования. Мы можем использовать, в большинстве случаев, родные языки систем, которые интегрируются, для отправки и приема сообщений;
- для гарантии доставки нам не нужно доставать бубны и велосипеды, если сообщение не может быть положено в очередь, то и транзакция будет безболезненно отменена;
- интеграция одной системы к многим и наоборот выполняется одной-единственной настройкой роутинга в RabbitMQ;
- простота формата сообщений, это бинарные данные — мы используем JSON, который переводится в бинарный формат;
- при высокой нагрузке, на довольно слабом виртуальном сервере, в очередь были доставлены все сообщения;
- каждый элемент системы не связан с другими элементами другой системы и бизнес-логика не дублируется, контроль целостности данных проверяется в едином месте в той системе, для которой эти данные предназначены;
- множество типов очередей, даже такие, что позволяют выполнять 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!"; } } }
С помощью 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. Время рассудит, станет ли это «серебряной пулей» или простой рабочей лошадкой для специфических задач интеграции.
Если вам помогла статья, благодарность можно выразить денежно.
Статья в личном блоге клац.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
(1) kauksi, 100 млн. это цены номенклатуры, большинство других расчетов так же содержат сопоставимые объемы. Статья не предназначена для большинства аудитории, больше на развитие. Используя только 1С:Предприятие невозможно добиться необходимой гибкости, отказоустойчивости и ценности для конечного покупателя. Тренд все больше смещается на уменьшение задержек обменов с поставщиками, мобильными системами, а так же произвольным анализом данных в невероятных разрезах. Будущее, в этом плане, пока точно не за 1С:Предприятие, а за небольшими сервисами. У нас плавно идет смещение, что 1С:Предприятие это система где хранится первичная документация, например, подача документации в контролирующие органы идет с помощью других систем.
А как можно подписаться из 1С на получение сообщений из очереди?
(3) pahalovo,
1С -> Очередь -> 1С. Реализовать прокси( и 1С SOAPHTTP сервис на принимающей стороне.
1С -> Очередь -> иная система. Воспользоваться примерами
(3) pahalovo, в принципе могу написать статью, как создать службу которая будет выполнять функции прокси-сервера. Правда на другом ресурсе, так как связь с тематикой 1С:Предприятие минимальная.
(5) напиши, будет полезно
(5) напиши, тема интересная. Как то искал готовое решение, которое бы забирало сообщение из очереди и пушило в веб-сервис. Пытался прикрутить для этой цели wso2. Сейчас понимаю, что написать свой адаптер будет проще и надежней.
(7) Вообще можно делать подписку на события
испльзуя например
Спасибо за статью! Очень позновательно.
(8) Serginio, а как отловить события, если не существует соединений на кластере серверов 1С:Предприятия и не запущен ни один сеанс, только висит один единственный Apache?
(10) Я делал отдельный сервис и через него отправлял и полученные события отправлял на вэб сервис 1С.
Отпрвавлял через пайпы
Кстати многие используют для таких вещей Вэб сервисы. Просто они тяжеловаты по сравнению с NetNamedPipeBinding
Кстати не пробовал, но так как статические классы остаются после загрузки их можно использовать и в 1С сервисе.
Можно держать регламентное задание которое будет запускать клиента Rabbit крутить вечный цикл и ждать события получать через AutoResetEvent через concurrentqueue
(12) Serginio, с регламентными заданиями так же проблем достаточно, да и лицензия расходуется и обработка в один поток всего.
(13) C# потоков ты можешь использовать сколько угодно. Кстати откуда данные, что регламентные задания лицензии используют?
Кстати здесь есть пример запуска асинхронных запросов и ожидания выполнения.
Показать
(14) Serginio, плюсом отметился, но с поддержкой замучаетесь, да и код понятен тому кто понимает в с# и 1С:Предприятие. Как по мне не зачем тащить внутренности c# в 1С:Предприятие, если мы теряем полезные фичи языка еще и сопровождаемость кода сильно усложняется.
Ого, статья про мой любимый rabbitmq 🙂
Практика показала, что лучше отказаться от всяческих фоновых заданий и смотреть в сторону событийной архитектуры интеграции. Принимать сообщения через службу-адаптер, которая подписывается на exchange с типом topic, и пересылает сообщения в соответствующие методы http-сервиса 1С. А отправлять сообщения через простенькую внешнюю компоненту. Таким образом получается асинхронный обмен, который происходит практически синхронно.
А уж чего стоит его плагин federation, который позволяет создать распределенную филиальную сеть и пробрасывать очередиexchange из центра в филиалы и наоборот.
В работе кролик ведет себя крайне стабильно, за пару лет использования не могу вспомнить его падений.
(15) Спасибо. Я как раз эту разработку делал для использования Вэб сервисов неподдерживаемых 1С с кучей классов. Отдельно писать очень муторно. А здесь создал сборку, подключил ссылку на сервис скомпилировал и все впорядке. Кроме того сделал поддержку событий и жизнь стала еще легче. Кроме того никто не запрещает сделать свою сборку как у тебя, только использовать через Просто в отличии от NETLoader можно использовать COM объекты. В данной разработке все .Net классы оборачиваются через Com объекты.
И можно например использовать AutoResetEvent для сигнализации о получении сообщения итд. Больше возможностей.
А зарегистрировать можно только на сервере и использовать любые нетовские сборки.
Я правильно понимаю, что проект который заморозили на zato, в итоге запустили на rabbitmq?
Можно подробнее развернуть про этот проект? Сколько систем участвовало в интеграции, кластеризовали ли кролика, использовали ли in-memory, плагин federation, shovel? Маршрутизацию настраивали руками через вебморду или использовали топики и ключи маршрутизации?
Рад видеть, что кто-то еще использует rabbitmq 🙂
(18) Bronislav, проект в замороженном состоянии, но уже практически его похоронили.
Проект на RabbitMQ новый и перспективный, он похож на первый проект но с существенным отличием — система с которой будет происходить интеграция будет разработана под наши требования, а не взята в аренду (в которой изменить по сути было что-то невозможно). Это, можно сказать, проба пера первые практические результаты будут примерно в начале мая. Проект можно грубо назвать — облачная система продаж.
По поводу настроек: и через веб-интерфейс и с помощью скриптов.
(13) ну не совсем так. Можно и в 1С сколько угодно потоков запустить с помощью фоновых заданий. В принципе, статья про многопоточность, а про реализацию мьютексов, если они необходимы (а в таких системах вполне могут пригодиться)..
По поводу того, что 1С — это не более, чем система для хранения первичных документов и ведения бухгалтерского учета — можно согласиться. Я считаю даже опасным на данном этапе развития экосистемы 1С попытки организовать на ней работу со всем и вся, хотя, конечно, она кое-что может. Но когда SLA информационной системы — это доли секунды, то 1С в этом месте делать совершенно нечего. Она или упадет, или зависнет, или еще что-то с ней случится. И тут либо помогают огромные вложения в технологический парк (которые в действительности помогают мало, т.к. 1С все-равно зависает и падает), либо такие же вложения в создание отказоустойчивых систем вне 1С, которым хватит имеющихся ресурсов (которые зависают и падают куда реже, и если это происходит, то по крайней мере есть возможность локализовать и устранить проблему)..
ЗЫ: Ну и конечно Win Only позиционирование статьи меня радует мало, но за понимание того, что на 1С свет клином не сошелся, однозначный плюс.
Про линукс версию 1С для промышленной эксплуатации думать рановато (и под виндой то еще вагон проблем), так что .Net здесь очень в тему.
(22) pfihr, а какие конкретно проблемы под Linux?
Делал подобное на MSMQ. Передавались сильно связные данные (более поздние сообщения не имеют смысла без более ранних). Возникла проблема, что делать серверу MQ если клиент не забирает данные из очереди. Очередь быстро растет, а очистить ее нельзя, поскольку 1с не сможет восстановить поток событий для очереди по требованию.
Это хорошее решение, когда передаются данные, для которых важно только текущее значение (например баланс клиента). Если же важна история, все сразу становится сложнее.
(24) matytsin_new, зачем очищать очередь? Очередь на то и существует что бы получить все сообщения. Если очередь растет — проблема не в очереди, а в 1С которая не забирает данные.
Если, что то вот еще один вариант обмена данными
(26) Serginio, тысяча чертей, лень читать и разбираться в простыне кода 🙂 хоть бы описание было: что? куда? и зачем?
(26) Serginio, немного разобрался, но все равно не могу понять в чем преимущество? Да EF и LINQ клевая штука, но не сильно производительная (в книге Metaprogramming in .NET рассматривают этот вопрос).
Нормально там с производительностью, уж значительно быстрее чем через посредника. Смысл в том, что ты можешь тянуть данные напрямую, без посредника. Я помню сам из Штатов так прайсы миллионные скачивал, правда из MySQL. Но суть та же.
И про скорость
ИМХО статья названа неправильно.
Про пороблемы OData ровно одно предложение и то оно ниочем. Думаю правильней бы назвать «Как надо использовать -кролика- RabbitMQ» или «КролеГ работает лучше, чем Zato ESB + OData»
Без обид, просто про проблемы реализации OData на платформе, о версии ее реализации как и о версии платформы в статье действительно нет ни слова.
(28) мне интересно как реализован слушатель…через регламентные задания?
(31) У ODATA по сравнению с SQL огромное количество ограничений.
Правда при использовании MS SQL настраивать MS SQL тоже нужно
Кроме того можно использовать HTTP и WEB сервисы
(32) См. 17
(32) minimajack, Win-служба пинает 1С HTTP-сервис, ждет пока 1С даст ответ что все отлично и сообщение можно удалять из очереди.
(31) dddxddd, описал в статье проблемы OData которые были важны, в первую очередь, для нас. Да, возможно, не описал качественных показателей скорости получения данных из OData и Native компоненты. Разница в скорости примерно в 1000 раз. Так же OData не дает возможности получить больших массивов данных это при наших 192ГБ оперативной памяти и 40 ядрах процессора… службы 1с просто напросто падают.
(0) круто !!!
На данный момент при обучении и внедрении я использую первый кейс.
Я вставляю событие ПриДобавленииСтрокиЧекаПродажи() -> ОтправитьВОчередь(«retail.api.check.add.line», _GUIDТовара, _CodeТовара, _DescrТовара)
В центре стоит подписчик которые рисует онлайн отчет с автообновлением под названием «Онлайн спрос на товар»
Отчет выведен на большой экран и показывает текущий интерес к товару.
Руководителям отделов продаж очень нравится.
Таким вот решением достигается такое, что данные по событиям с кассовых мест получаются в центре не более чем через 15 секунд
2 плагина необходимы для этого
(0) За ссылку на наше 8 часовое веселье спасибо. Применительно к ZatoESB я со сцены Инфостарта передавал вам привет, за наводку на неё. Передаю и тут 😉
(28)
Первая причина это ты, а вторая все твои мечты… 🙂
(35) Кстати какой формат использовали? XML,JSON?
Использовали ли при запросах gzip?
(39) Serginio, формат сообщения JSON, который конвертируется в байты. Если понадобится сможем использовать Deflate.
(40) Я про ODATA какой формат использовали?
Кстати, а ProtoBuf не хотите использоват?
(42) Serginio, зачем? данные не предназначены для систем, которые работают на .Net. .Net у нас прослойка для отправки сообщений в очередь из 1С и получении сообщений из очереди в 1С.
(41) Serginio, частично XML, когда появилась поддержка JSON начали использовать его.
(42) Serginio, нахрена козе боян? протобуф из другой оперы …
(44) Из той. Он быстрее и компактнее, классы .Net тоже могут прослойкой.
(43) И какова разница использования Odata с JSON и XML?
(45) Serginio,
1. Лишняя прослойка
2. Скорость будет медленнее нативной сериализации
3. Нет готовых библиотек для 1С
4. Нет сложных классов для передачи (только в таком кейсе протобуф выгоден)
вывод: лишние костыли в инородной системе
зы быстрее и компактнее не про 1С. Сэкономленные 5% трафика — смешно по сравнению с рисками и дополнительными косяками.
ззы от пиара .Net уже тошнит ей богу — такое в ентерпрайс пустят только гики.
(46) Нет не будет. Можно использовать любые .Net библиотеки
Еще раз с помощью .Net классов можно решать любые задачи без использования ВК.
Другое дело, что самым быстрым будет прямой доступ через SQL. Можно использовать ADO.
Кстати данная разработка тоже построена на .Net. Тебя это почему то не коробит.
По какой причине, не использовался продукт Axelot ESB? На текущий день, это коробочный продукт, непосредственно под эти цели, включил — работает; Из за того что он новый и появился недавно?
(47) iTony73, информационный поток очень большой и за всем сложно уследить. Спасибо за ссылку, ознакомлюсь.
(48) Serginio, меня интересует не реализация — а подход.
Использовать MQ — хорошо, OData — нормально(нет транзакционности из коробки), ADO — бред, EF — бред.
зы имхо, объяснять почему что то хорошо, что то нет — не хочется; но кровавый энтерпрайз диктует свои требования.
(50) Вот и пришли, что нетовский клиент RabbitMQ это хорошо, а другой нетовский класс это плохо. Где логика?
Про ADO расскажу такую исторю. Нужно мне было загружать миллионные прайсы в регистр сведений. Загружать через набор записей очень долго, так как удаляются все записи, а потом записывается опять полный набор. По одной записи обновлять, удаляь и добавлять тоже накладно. Но вот загрузить из текстового файла булками в темповую таблицу и использовать Merge для объединения данных решило проблему. Там где было десятки минут, стало пару минут. По твоему это бред. По мнению моей конторы это огромное облегчение труда и удобства для клиентов.
(51) Serginio, MQ — message queue — по русски очередь сообщений. Использовать очереди это хорошо, то что используется .Net — мне не нравится.
— ну что тут сказать…тут вариантов тьма. Важен кейс использования этих данных — по видимому проблема в архитектуре приложения.
(52) minimajack,
Проблема в том, что еще клиенты просят прайсы с наилучшими ценами. А количество позиций по десякам прайсов было по 100 миллионов. Там еще использовалась конструкция WITH TIES для отбора по цене и остаткам на складе. Все делалось для клиентов. Но это было быстро и удобно. При этом работали и вэб сервисы, как к нам так и от нас.
В чем проблемы в архитектуре?
(53) Serginio, надеяться на 1С8 загружая стомиллионные прайсы и ожидая отклик в несколько минут
(54) minimajack, нет проблем до сих пор. Так, как запись все в обход 1С. А вот что касается поиска и прочее 1С прекрасно работает уже лет 7. Что я делаю не так? Кстати про WITH TIES
(0) из статьи не уловил — куда ушел OData из связки с 1С? 1С каким механизмом вызывается со стороны очереди? Или она только кладет что-то в Rabbit и извне не вызывается?
(56) Evil Beaver,
костыль в общем)
Добрый, а почему выбрали именно RabbitMQ, чем он хорош этот менеджер очередей ? что кроме организации очереди может реализовать. Возможно ли трансформация передаваемого пакета.
Не рассматривали IBM WebSphere MQ, правда стоимость его не совсем привлекательная.
(58) AKulakoff, добрый день, выбрали потому, что стоимость и порог входа минимальный, а так же делаем точки соприкосновений различных языков (php, python, c#, 1C, JavaScript). Это дает возможность использовать другие технологии, с которыми в 1С есть проблемы, например: гарантия доставки сообщений, dash boards, мобильные приложения, версионирование объектов, для поиска — ElasticSearch и т. п.
В трансформации пакета, не вижу надобности. Все данные ходят в формате JSON, в случае если другой системе понадобятся данные она подпишется на необходимый обмен со своей анонимной очередью.
(58) AKulakoff, отличная скорость доставки сообщения из 1С:Предприятие (с помощью Native компоненты) в RabbitMQ занимает это дело около 5-7 мс. В принципе можно посмотреть на пульс обмена и понять, когда происходят пики нагрузки.
(6) Tahallus, (7) pahalovo,
(18) Bronislav, вот как-то так выглядит схема использования у нас
(62) pbazeliuk
Отлично 🙂
Exchange с типом топик используете?
Насколько понял из схемы, 1С ничего не знает о мобильных и веб приложениях и они как постоянные подписчики работают?
(63) Bronislav, не постоянные, если кто-то подписывается он создает свою анонимную очередь и добавляет bind в exchange (какие именно события отлавливать), при отписке очередь автоматически уничтожается. По похожем принципу работает RPC. Да exchange с типом topic.
В итоге руками только созданы 3 объекта — rpc queue, exchange queue и log queue, все остальное динамическое.
(62) а чем такую чудесную диаграмму рисовали?
(65) Evil Beaver, да у меня жена профессиональный дизайнер, в декрете скучно ей, подрисовывает (Adobe illustrator) 🙂
(59) Трансформация обычно нужна, когда один объект летит в несколько баз и для каждой базы требуется свой пакет.
Так было в моем случае, но решение было на IBM WebSphere MQ, правда порог входа в нее совсем не бюджетный …
А есть статистика сколько пакетов проходит за определенный период (час, день)
(67) AKulakoff, около 10 тыс. сообщений в час, но это пока тестовый режим. Дальше будет видно.
(58) AKulakoff, ВебСфера очень дорого… прям запредельно… в том числе по стоимости владения, а не только по лицензиям. Как и другие платформы интеграции за авторством Java программистов.
лучшей реализации AMQP кроме RabbitMQ для production сейчас не найти.
(68) кстати насчет Zato + OData. Я как то говорил, что проблема не в этой связке как таковой — Zato удобная для понимания концепции ESB. Но Zato заточено под EDA —
C точки зрения EDA OData протокол реализациия в 1С слишком избыточна — 1С-ные объекты «большие». Поэтому ZatoESB у нас на методических проектах используется только как сервис создания API и сервис интеграции одного API в другое.
(69) lustin, эээээээ!! А как же ?
добавляем везде слово ИМХО
для интеграции с 1С практически все равно какая MQ…1С просто не загрузит шину ИМХО =))
(0) еще раз пересмотрел название очередей. Пётр — вопрос, а вы серьёзно подходили к разработке routing topologies ? Если в статье указан пример — то ладно, а если реальные наименование, то они «слишком абстрактные».
(73) lustin, на самом деле все по другому.
Вот это реальная схема получения информации из 1С
Оповещения о других событиях 1С идут в Exchange (1c.events), по определенным routing keys. На оповещения подписываются анонимные очереди.
Схема работы примерно такая: запускается сторонний сервис, получает полную информацию по схеме RPC, паралельно создает анонимную очередь и подписывается на определенные события (1c.events). Когда сервис отключается, анонимная очередь уничтожается. Пакеты о событиях нумеруются, что бы сервис понимал что произошел сбой сети и снова получил полную информацию по RPC.
Круто. но нифига не понятно.
гугел, я к тебе -))
(72) lustin,
Просмотрел этот проект, на сколько понимаю, проба пера? Потому, что для больших нагрузок (несколько тысяч сообщений в секунду) и больших трансферов (больше 500MB) не предназначен. Хотел спросить может есть у вас Native компонента для 1С для отправки? У себя пока используем hosting CLR, но по производительности при высокой частоте сообщений появляются проблемы.
Тебе стоит посмотреть в сторону асинхронного выполнения методов
(77) Serginio, сервис, для RPC, работает асинхронно, с ним все отлично. Проблема больше в компоненте 1С которая передает данные, проблема не в размере передачи данных, а в частоте их передачи.
(78) Я говорю про асинхронную передачу из 1С
Там есть пример
Показать
И сама процедура
Показать
Наверняка у RabbitMQ.Client есть асинхронные методы
(79) Serginio, при использовании HTTP больших размеров падает RabbitMQ. Для больших данных только TCP.
(80) Serginio, . Нет реализации еще.
Ну можно и самому вызов в Task завернуть. Главное, что бы 1С не ждала результата. Странно, что RabbitMQ.Client не используют. Асинхронные методы уже стандарт в .Net
Второй вариант это 1С кладет данные в очередь, а уже отправкой занимается класс на C#. Скорость вызова на моей кроссплатформенной компоненте порядка 40 000 вызовов в секунду.
Но проще запускать Task.Run а внутри планировщик сам создаст очередь
Ну вот почему то про очереди все славно поговорили…. а про трансформацию ни слова.
А это самый геморрой.
(86) Mambetin, а что есть какая-то волшебная таблетка от геморроя при трансформации? Как не крути, а трансформация всегда будет геморроем и тут без разницы — будет это в 1с, в какой-нибудь esb шине или еще где-то.
(87) pumbaE, так вот и интересно кто в каком месте подорожник прикладывает. в 1С или в очередях колдуют
(88) Mambetin, на стороне 1С конвертируешь объект в json (можно даже сделать универсальный конвертор), а далее те кому он нужен (внешние системы) пусть с ним и разбираются.
(89) в каноническую универсальную структуру объекта ?
(76) ох ты… а я пропустил это сообщение
На bitbucket — проект просто обучающий, в рамках понимания тех кто только начинает.
есть такое — если про NativeAPI, там BDD, CMake и кроссплатформенность. Сейчас в пилотировании.
собственно это то что мы активно делаем сейчас уже как 3 месяца… Еще и mqtt протокол.
(92) lustin, было бы интересно почитать про возможности и концепцию работы в понимании вашей команды.
Со своей стороны, планирую в недалеком времени первичные наработки выложить (те, что вот, от которых будем отказываться в пользу более мощных и универсальных подходов).
Если быть более точным, то вот это: Hosting CLR + Win сервис, ну и базовый код к нему. Это бесплатно, не сильно удобно и с некоторой стороны тяжело в разработке. Так же расписать некоторые нюансы работы с кроликом.
А вот следующий за ним конструктор, библиотека Native API, а так же библиотеки проверки «1С объектов» платно и дорого. Как говорится не только ж события слать, а и создавать эти же «1С объекты».
(93) А почему не хочешь
На примере
(94) Serginio, от .NET полностью не собираюсь отказываться. По сути уже целый год прорабатываю различные схемы интеграции и построение сложных систем. Понимаешь есть понятия, как паттерны проектирования, расширения объектов, разграничения ответственности, DI и т. п.
Мне, вот чесно, сложно представить как поддерживать такой код как у тебя, подход возможно стоит внимания, но в плане сопровождаемости он ужасен. Кроссплатформенность под вопросом (под .NET Core нет еще много библиотек, того же ), а поднимать разные слои для взаимодействия простых объектов — лишние затраты программистов и администраторов. Может конечно для небольших внедрений он идеален, но моя цель большие предприятия с большим зоопарком систем и гигантской нагрузкой онлайн.
(95) SignalR выйдет в 4 кватале либо в первом 2017
Что касается Hosting CLR + Win сервис то он значительно менее функционален по сравнению с новый COMОбъект(«NetObjectToIDispatch45»);
Так как поддерживается почти все классы .Net, а внутри используют те же механизмы COM.
Единственно, что нужно регистрировать одну библиотеку. Но все остальные сборки вызываются без регистрации.
Другое дело, что зная ClassID можно создавать IDispatch и без регистрации
Для .Net Core на днях выложу аналог
А вот, что касается Native API то нужно как то влиять на 1С, что бы они расширили возможности ВК.
Так они наконец дали возможность передавать в параметрах ДвоичныеДанные. Только все это медленно
(22) pfihr, а потом, когда linux будет в тему, что делать с тоннами legacy-кода? Кросплатформенность — это такая штука, о которой правильно думать сразу, а отложенная на потом — она будет отложена навсегда или ляжет тяжким грузом на того, кто будет сопровождать систему после «горе-разработчика» напихавшего в неё COM/ActiveX/.NET
.NET может быть с очень большим натягом кросплатформенным, но на средних и больших проектах, особенно в связке с 1С — это будет стоить огромных усилий.
(72) lustin, Ищу решение для задачи: обмен сообщениями между приложениями на разных платформах, с возможностью подключения новых неизвестных приложений. Сообщения — это набор электронных документов и операций по конкретным бизнес процессам между компанией и ее клиентами, формат сообщений свой. У сообщений будет единый согласнованный формат, но приложения могут оправлять сообщения как в согласованном формате, либо в своем формате который затем будет конвертироваться. Нужна поддержка синхронного и асинхронного обмена с гарантированной доставкой.
Как я понял, ESB и Шина сообщений решают эти задачи. Остановился на Zato ESB, т..к. она бесплатная, поддерживает создание сервисов, конвертацию сообщений, разработку своих адаптеров.
Товарищи, наставьте на путь правильный: или скажите где дальше копать.
1) Имеет ли Zato в своем составе Шину сообщений, поддерживает ли она гарантированную доставку и асинхронный обмен сообщениями?
2) Исходя из описания на сайте Zato и комментарий Алексея Лустина, где он пишет про использование Zato ESB + RabbitMQ, предположу что Zato не поддерживает эти функции, поэтому используется в связке с Rabbit, потому что он это поддерживает ?
3) Второй момент, тут в комментариях упоминалось что Zato больше подходит под решение задач где применимы модели EDA и SOA. Под эти модели хорошо попадают задачи выполнения операций (исполнение бизнес-процессов, транзакций и пр.), а для просто надежного обмена сообщениями (например обмен между базами 1С) подходит просто Шина сообщений (RabbitMQ). Предположу что для моей задачи применима модель SOA с созданием сервисов в Zato.?
Буду рад позже поделиться своим опытом. Всем спасибо!)
(109) dm2010, Zato имел свою проблему, что он падал без причины. Разработчик через год устранил проблему, но не понятен цикл и будущее развитие Zato как сервиса.
Zato имеет поддержку RabbitMQ;
Возможно, как и EDA так и SOA. Но если использовать одну из моделей тогда придется пожертвовать чем-то, например: асинхронностью или гарантией доставки или транзакционностью. SOA это сильное связывание приложений, EDA слабое.
Если уже есть техническое задание, смогу подсказать что можете использовать.
(110) Спасибо. Техническое задание готовлю, как можно с Вами связаться?