Пришли новости из зазеркалья: https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/

Появляется некая "Интеграционная шина". В статье куча красивых и умных слов, но прочитав ее несколько раз я так и не понял: в чем суть-то?
Она привносит что-то принципиально новое в обмен 1С с другими информационными системами? Или "те же яйца, только в профиль". Кто-нибудь понял функционал нового решения?

(0) Ну это типа ты раньше сам делал такую шину, а теперь будет готовая, но со своими глюками.

(0) ну типа ты раньше сам прикручивал 1С ко всяким rabbitmq то теперь есть свои костыли этого плана (и страдать будут те кто другие сервисы к ней подключают, а не одинесники)

Я ксатти так и не понял почему " не является альтернативной механизмам планов обмена,"?
У меня как раз первая мысль была замена тормознутой регистрации изменения

(3) ДОставка пакета и регистрация изменений разные задачи, поэтому логично

Хм... К 19му релизу, наверное, можно будет пользоваться...
Если рабодатель к тому времени расщедрится на корп...

(3) Это не замена регистрации изменений.
Это замена (скорее всего) всяких фтм, емыла, каталогов и прочего для обмена пакетами данных...

И конечно же это будет КОРП-функциональность или "сервер интеграционной шины" можно будет купить отдельно.
А так - прикольная тема.
(3) Ну, в качестве транспорта для доставки изменений теоретически использовать можно. Но на больших объемах фиг его знает. Так "сломанный" обмен между базами кушать почти не просит, а тут будет быстро забивать канал. И не очень понятно, как это все потом разгребать.

(0) В типовых конфигурациях появиться еще 50 общих модулей в перфиксом "ИнтеграционнаяШина" и тогда высшие джедаи станут овладевать этим знанием. Потом про эти механики забудут.

(0) Вообще шины данных это стильно, модно, молодежно. Вещь нужная для интеграций разных подсистем. Вместо всяких кроликов пойдет.

(0)
Крутая тема, изучи RabbitMQ.
Не известно, правда, как они там это реализовали.
Такой продукт от 1С давненько напрашивался.

версия:
на самом деле всякая кустарщина по обмену в конторах пишется толковыми ребятами и весьма непросто оттуда что-то получить без палева, а при помощи шины пожалуйста - любые внешние данные предприятия можно будет пропустить через "шину" в бездонное хранилище для скурпулезного анализа сторонними лицами.

(9) "этому модно стильно" уже лет 20 как

Кто нажал зеленую кнопку Попробовать, признавайтесь :)

(4), (6)
- Отправляемое в «Интеграционную шину» сообщение сохраняется в информационной базе до тех пор, пока от «Интеграционной шины» не будет получено подтверждение того, что сообщение им получено.
- Система 1С:Предприятие будет выполнять попытки доставить сообщения «Интеграционной шине», пока не будет получено подтверждение получения сообщения или сообщение не устареет (у сообщения может быть установлен «срок годности»).
...
Зачем мне регистрировать изменения? Смылс регистрации, чтобы потом скопом выбрать измененые. В данном случае я сразу отправляю пакет в шину (онлайн обмен с шиной) и платформа сама пытается долбиться в шину, сама сохраняет в базу пакет для отправки пока не получит ответ от шины. Т.е. зачем мне промежуточное звено в виде механизма регистрации изменений если платформа все это дело дублирует при попытки отправить пакет в шину?

(14) > Т.е. зачем мне промежуточное звено в виде механизма регистрации изменений если платформа все это дело дублирует при попытки отправить пакет в шину?
Потому что в противном случае шина у тебя автоматически становится главной точкой отказа

(14) Регистрация изменений нужна для того, чтобы знать, чем пулять в шину.

(16) Так пуляй при окончании транзакции записи, так все делают :))

(16) Пулять ты можешь тупо из подписок.

(17) (18)
"Пуляй и теряй" (с)
см. (15)

(19) В нормальном режиме ты не теряешь. Вопрос, как поведет себя сервер интеграционной шины под большой нагрузкой и с засранными каналами.

(19) Дык надо так пулять, чтобы не терять.

Ну и когда он ляжет, то дружно ляжет работа всех баз.

(16) еше зачем регестрировать изменения вбазе? у тебя есть объект (документ) и тебе нужно запулить его в шину.
Что сейчас
1. Регеитрируем в отдельную таблица этот объект  (таблица изменений)
2. Запускаем обработку которая выберет ВСЕ объекты и проставит им номер и отправит в таблицу изменений для шины (Отправляемое в «Интеграционную шину» сообщение сохраняется в информационной базе)
3. Платформа выберет все изменения из таблицы изменения шины и будет долюбиться в шину пока не положит сеть, ну или не отправит сообщение.

Т.е. мы одини и теже данные пишем в 2 разные таблицы которая использует только платформа. Так почему сразу не писать в таблицу изменения для шины минуя 1 таблицу?

(20)
Вот я про то же

(21)
Это от тебя не зависит, а зависит от шины, и ты её состояние не знаешь в текущий момент времени

(15) Нет, пока данные не отправлены они дублируються и хранятся в ИБ, пока шина не даст подтверждение
(20) ккакая разница пулть по окончанию транзакции и путь они висят в очереди на отправки или пулять порциями из 100500 объектов выбирая их из таблицы регистрации?

(25) Что мешает сделать подтверждение получения сообщения от шины?

(27) оно и так есть

(26)
"Нет, пока данные не отправлены они дублируються и хранятся в ИБ, пока шина не даст подтверждение"
===
Это и есть "очередь сообщений"

(27) "Система 1С:Предприятие будет выполнять попытки доставить сообщения «Интеграционной шине», пока не будет получено подтверждение получения сообщения "

(29) и?

(30) Вот, интересный вопрос, где и как будут храниться сообщения до получения подтверждения.

Короче, интеграционная шина предприятия концептуально штука очень вкусная, так как на нее можно сгрузить кучу сложных проблем.
А на практике это будет еще одна штука, которую нужно очень бережно админить и плотно мониторить. Потому что залетевший туда дятел сломает вообще все.
(32) Очевидно же, что в собственной БД. Не удивлюсь, ежели внутри кролик и будет или что-то в этом духе.

(32) "Отправляемое в «Интеграционную шину» сообщение сохраняется в информационной базе до тех пор, пока от «Интеграционной шины» не будет получено подтверждение того, что сообщение им получено."

Я так понимаю будет еще один аналог таблицы регистрации. Ну или жесть с одной единственной таблицы куда будут писаться все данные.

(33) Не собственной а в той же БД где хранятся данные, таблица изменений для планов обмена и будет еще одна таблица для очереди сообщений для шины

(35) Готов поспорить, что это будет отдельно стоящая штука. Как сервер взаимодействий.

(34) А чего бы и не в одной таблице, если в виде бинарных данных?

(35) Судя по описанию, шина то-же будет хранить сообщения.

(20) "Доступны данные мониторинга работы Процессов интеграции: количество обработанных сообщений, ошибок и пр."

"Источником сообщения может быть файл,"
"При необходимости можно трансформировать сообщение при помощи процедуры на встроенном языке."

Интересно а можно написать загрузку прайсов? Или вытащить шину наружу, типа пуляйте сюда свой прайс и дальше шина обработает данные и загрузит в нашу базу

(38) я так и не увидел этого в описания. т.е. будет ли шина долбиться пока не отдаст или будет хранить у себя периодически опрашивая доступность получателя

(40) Брокер сообщений не обрабатывает данные. Его задача только гарантировано передать потребителю.

(41) В общем, надо пробовать, пока бесплатно предлагают :)

(39) Угу. "количество обработанных сообщений: 0, ошибок: 134234543523". И ты чешешь репу перед разрывающимся телефоном.
Я не к тому, что это ненужная штука. Штука наоборот очень нужная. Но и голову выключать не стоит. Оно не волшебная палочка. За все надо платить и цену нужно понимать.

(42) Тогда что означает "при необходимости можно трансформировать сообщение при помощи процедуры на встроенном языке."?

Причем сообщение это "EnterpriseData"

Я не понял из мутного описания как у них реализован subscriber. Гарантированно пулять в любую queue нет проблем и сейчас.

(47) Предполагаю, что службой кластера

Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляМагазинов». Полученный JSON отправляется в канал «ДляМагазиновСоСтарымПО». Т.е. шина как раз и занимается заменой. Такая КД 4.0

(46) Где написано, что только EnterpriseData? Это вроде как пример просто приведен.

И какие-то обработчики серверных событий будут доступны

(50) так вот я и спрашиваю в (40).
На входе прайс от поставщика, внутри шины (в трансляторе) мегапрайс, на выходе из шины уже обработанные EnterpriseData, которые останеться только загрузить  в 1С

(52) Надеюсь, что всё это гибко настраивается, и никакой привязки к форматам нет.

(51) это шина _между_ базами

(54) что не отменяет обработкика типа
"При получении данных от шины"
При загрузки данных от шины"

Опять же, непонятно - отправителем может быть только 1С или кто угодно?

или как, каждые 2 секунды опрашивать базу на предмет, "были ли данные о шине"?

(57) Тогда смысл в этой "шине"?

(56) "Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система (такие системы называются участниками взаимодействия)."

(58) Ну ведь они же так сделали в фоновых задачах, когда клиент опрашивает постоянно результат работы в надежде что можно забирать данные. Что им мешает сделать по аналогии. Может они не знают что можно как то по другому

(57) Там написано что они сделали механизм вызова.
"Для поддержки асинхронного обмена сообщениями в платформе 1С:Предприятие версии 8.3.17 добавлен механизм сервисов интеграции. Обмен сообщениями происходит по каналам, организованным на сервере. Канал – это однонаправленный поток сообщений от отправителя к получателю. Сообщения в канал помещаются последовательно отправителем и последовательно доставляются получателю. Сообщения разных каналов обрабатываются и доставляются параллельно."

(54) Ну а кто запушит сообщение "в базу" от сервера шины интеграции? Очевидно же, сервер шины интеграции будет пушить в кластер, а кластер будет пробрасывать пуш в базу. А программист 1С поймает подписку на серверное событие в конкретной базе.

(54) Это же асинхронный обмен между базами, а не синхронный. И посредником выступает сервер шины интеграции. Причем база-источник отправляет и "забывает". А сервер шины интеграции уже мурыжит базу-приемник, пока та не проглотит.

(45) Возможно предполагается, что шина может преобразовать данные для конкретных потребителей. Фишка просто.

(3) Если мы говорим про гарантированную доставку, то план обмена является частью общей схемы, а не альтернативой

(65) Шины подобного рода как раз и используют в качестве средства гарантированной доставки. Это их главная фишка. Другое дело, что лично я бы трижды подумал, прежде чем использовать ее в 1С в качестве альтернативы. Потому что есть как свои плюсы, так и свои минусы.

(58) Данные отправляет отправитель
А получатель опрашивает, нет ли свежих данных

(65) В смысле, если мы хотим знать в отправителе, что сообщение получено?

(66) Ну да ну да
И что делать, если у тебя брокер сообщений по какой-то причине недоступен?

(65) что именно такого может план обмен что не может шина интеграции от 1С?
Единственное отличие что в случае планов обмена ты должен сначало загрузить в приемник а уже приемник сформирует подтверждение
А в случае с шиной ты получшь подтверждение от шины, а не от приемника. Т.е. возможно ситуация когда ты отправил, шина получила, но до приемника инфа так и не дошла.
Но это нивелируется "Сообщения, отправленные в один канал в определенной последовательности, будут получены в той же последовательности." Т.е. пока первое сообщение не будет загружено, у тебя последующие не будут грузиться.
Причем загрузка сообщения в ИБ не означает успешного прохождения пакета

(68) Нет, если мы хотим быть уверены, что оно отправлено
Грубо говоря, я записан нового контрагента и попытался его толкнуть в брокер сообщений (ну то есть шину, если кому непонятно)
А он по какой-то причине недоступен (комп с брокером завис, инет упал, сеть тупит, что угодно)
В этом случае нужно куда-то записать "Не забыть попозже еще раз попытаться отправить контрагента в брокер"
Для этого как раз и используется план обмена

(66) Вокруг шины можно строить разнородную инфраструктуру. Сейчас 1С приходится интегрировать с существующими брокерами более или менее заморочено. С этой шиной можно будет быстрее интегрировать учетные системы с разнообразной инфраструктурой (уже остальную инфраструктуру надо будет прикручивать к ней)

(70) Читай (71)

(71) Бред

(67) [А получатель опрашивает, нет ли свежих данных] - ну это как-бы забегать каждый день на почту, чтобы проверить не пришла ли посылка.
Я так-то хочу, чтобы мне почтальон в дверь позвонил

(71) Зачем для этого план обмена? Можно же сами сообщения харнить, пока от шины не получим подтверждение получения сообщения шиной.

"Отправляемое в «Интеграционную шину» сообщение сохраняется в информационной базе до тех пор, пока от «Интеграционной шины» не будет получено подтверждение того, что сообщение им получено."

(69) Тоже самое, что и когда по какой-то причине станет недоступен сервер 1С. Об этом я тоже выше писал :)

(72) Спорное утверждение
Тебе нужно только толкнуть что-то в кролика или прочитать из него, а другим системам как раз будет проще работать со специализированным широкораспространенным продуктом
А тут сиди, затачивай под новый продукт

(74) Рукалицо

(76) План обмена - это средство накопления изменений с одной стороны, и их "мержа" с другой. Доставкой он не должен заниматься

(80) см (77)
Этим шина занимается на уровне платформы
Тогда в чем разница?

(79) Они декларируют поддержку протокола AMQP, это вроде помочь должно.

(81) Ну да, то есть для обмена сообщениями с шиной он и не нужен, в общем случае.

(79) Это да. Сейчас вокруг распространенных брокеров выросло много легаси, которое никто не будет переписывать. Можно только надеяться, что вокруг шины 1с что-то вырастет. Хотя по мне лучше бы заморочились с интеграцией того же кролика, по типу внешних источников данных.

(75) Да, я тоже согласен с таким желанием
А вот glebushka против, типа брокер ничего не знает про получателей и не должен знать, кому нужно, тот сам зайдет на почту

(86) Он в 1С не работает, так что может быть против чего угодно :))

(67) Если оно так будет, то я животик надорву.
Но я сильно сомневаюсь, что фраза "сообщения последовательно доставляются получателю" означает "получатель последовательно выгребает сообщения самостоятельно"

(88) Про это почтальон Печкин ещё объяснял: "Если посылка пришла, её нужно принесть. А если документов нету, её не надо отдавать. Я к вам так цельную неделю ходить стану"

(89) Так оно так и будет. Печкин же приносил посылку, а не сидел с ней на почте. Так и шина ее будет приносить, пока не заберут.

(88) означает

(89)+ Это, кстати, хороший момент - авторизация доставки

(88) "При получении сообщения от «Интеграционной шины» это сообщение сохраняется в информационной базе, и только после этого «Интеграционной шине» подтверждается получение сообщения."
Заметь не результат загрузки, а именно сообщения (к примеру xml файл внутри которого сидят данные в формате EnterpriseData).
Т.е. получается сообщения пишется в некую отдельную табличку, которую программист должен опросить и загрузить в базу. Правда в случае ошибки не понятно что делать (например структура поменялась и он не смог загрузить)

(88) (91) Есть же еще вариант, что Печкин принесет "квитанцию", а за посылкой Матроскин пойдет на почту самостоятельно.

(94) пока из описания этого не следдут. Разница лишь в том что опрашивать шину или в случае с шиной от 1С табличку изменений в базе, куда шина доставила сообщение

Интересно можно ли сделать так чтобы источник и приемник совпадал. Т.е. выгрузить реализацию и загрузить эту реализацию как поступление в эту же базу, но по другой фирме

(92) Не будет никакой авторизации доставки. Будет авторизация для настройки этого всего хозяйства и все. Ведь получателем фактически будет "база", а не "пользователь". Как и отправителем. Это чисто системный механизм.
(94) Это детали. Главное, чтобы модель была событийная.

(96) А почему нет?

(97) с чего это вдруг? "Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система" - т.е. отправителем может быть что угодно начиная от файла, вклая сайтом где клиент бъет заказы или агригатор

(98) Потому что 1С

(100) А, понятно

Я начальство уговариваю на попробовать, а то гадать смысла нет особого.

(99) Ты про авторизацию или кто может быть отправителем? Не, про отправителей понятна. Будут внутренние механизмы для баз 1С, API "наружу" и возможность натравить шину на "папочки", на которые она будет "зырить" и сама генерить сообщения.

Kafka не держит AMQP, когда кафку прикрутят, будет интересно попробовать, а пока чет как-то так себе.

(104) Почему такая фиксация на кафке? "Kafka не держит AMQP" по одной простой причине - кафка не является классическим сервисом очередей сообщений. На кафке его можно построить. Но будут свои приколы.

(105) из коробки кафка его не держит, а так есть конечно дополнения для поддержки этого протокола.
фиксация на кафке - потому что на ней у нас сейчас и построено подобие интеграционной шины.

(106) Ну и толку вам с того, если продукт от 1С будет внутри кафку юзать? Как это вам поможет? Разве что админить придется уже привычную хрень и не плодить "админские" сущности.

(107) да, появись оно 2 года назад, может быть и не пришлось бы кафку юзать, а оставаться в рамках "экосистемы 1С".

(36) Не тупи - как отправляемое из конкретной ИБ сообщение может оказаться в какой-то еще "отдельной ИБ"?

(0) Это для каких-то единичных проектов.
Ощущение, что возможности разработчиков в фирме 1С стали сильно превышать возможности специалистов, обслуживающих программы от 1С в остальной стране. В 1С просто не знают чем их занять, и плодят новые проекты.

(71) "В этом случае нужно куда-то записать "Не забыть попозже еще раз попытаться отправить контрагента в брокер"
Для этого как раз и используется план обмена" // Это твои домыслы, вероятность задействования каких-то планов обмена в адаптере, вшитом в платформу, ничтожно мала.

(109) Если это был вопрос мне, то я его не очень понял. Ответ - с помощью сабжевой штуки.

(112) Цепочку сообщений (цифры в круглых скобках )взад отматывать не умеешь что ли?
https://i.imgur.com/sTBpdkK.png

(113) Очевидно, нет. Потому что я опять ничего не понял. Ну фиг с ним. Пойду чайку попью.

(109) Потому что сабж - отдельный микромир с графическим конфигуратором, со своим интерпретатором кода (транслятор) и мониторингом состояния. По твоему весь это колхоз в инмемори живет? Логично что как и сервер взамодейтсвия у него своя база для хранения данных

AMQP в 1С? Если это будет работать - однозначно прорыв! Фича востребована рынком уже десяток лет, наконец-то это поняли в зазеркалье.

(0) в принцепе здесь описан механизм КД-3 и ничего нового, 1с это внедряет уже много лет... идея здравая и хорошая, но сейчас ее реализация очень сильно страдает из-за сложности внесения чего ли-бо нового в обмен

(0) Service Broker в скуле .

(0) в принципе все норм . типовые   не пилить и ставить в обмен с другими  приложениями  НЕ  1С

(115) О чем ты?

(117) Я так понял это не в замену КД3. Это для автоматизации транспорта сообщений/файлов

У SAP есть PI, теперь и у 1С будет. Лично я рад.

(121) КД-3 построена на собственной фабрике которая описывает формат этой самой транспортной шины,

то есть сабж - это часть технологии КД-3 (видимо слегка адаптированая к не 1с данным).

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

(123) Какая фабрика, какая шина, какая КД-3?
Ты в (117) просто вообще пальцем в небо
1С сделала шину данных, а ты что-то говоришь про то, что в ней используется идея, похожая на КД-3
Где, нахрен, в КД-3 шина данных?
КД-3 — это выгрузил куда-нить данные, кто-нить их загрузил и как-то интерпретировал, шины данных здесь нет вообще в принципе
Это примерно то же самое, что говорить, что файловая база — это примерно то же самое, что и трехзвенка, просто там формат скулевый

на самом деле,план обмена никак не отвечает за доставку,его функция-гарвнтировано доставить данные,если хотя бы один пакет дойдет.
опять же,доставкой в плане обмена считается получение подтверждения о том,что другая сторона получила данные и прислала ответ. при этом,если одно сообщение обгонит другое,то ничего страшного не произойдет.
но,проблемы плана обмена начинаются,когда получателей несколько,так как обмен в модели 1с возможет только между двумя точками,если что-то сложнее,то это уже нетртвиально администртровать.

очередь сообщений строится на том принципе,что сообщение гарантировано доставляется,то есть,если не доставится одно сообщение,то последующие также не дойдут,это позволяет отправлять сообщение сразу в несколько источников.
но,очередь сообщений,это просто среда передачи-сообщения доставляются неизменными.

а вот если мы хотим не только доставить сообщения сразу нескольким получателям,но и еще и преобразовать их,а также не думать при отправке,кому и что доставлять-пусть среда доставки сама все решает-вот тут и появляется то,что называют шиной.
но,не очень понятно,зачем изобретать велосипед,если есть бесплатные решения типа sinapce
единственное,что наличие возможности писать сценарии на языке 1с требует,чтобы была возможность его выполнять. опять же,специальная распределенная база 1с вполне под это подходит,только нужно назвать это все по-умному и приподнести как  кардинальный прорыв.

(125) Там же сидят таланты, поэтому не мешай им талантировать

(110) да ладно, то что в каждой конторе проги  1С лепят каждый в силу своей распущенности, приводят к какому то стандарту.

Вот у вас разве нет справочной базы, и обменов с остальными?

(124) что по твоему разумению есть шина данных?

в моем понимание это есть отдельная база с неким универсальным интерфейсом позволяющая хранить данные обменов внутри себя в своем внутреннем формате и умеющая отдавать их во внешний интерфейс, по сути КД-3 это и есть работа с таким файлом, формат файла и его взаимодействие с миром определены фабрикой ( и реализованы в стандарте EnterpriseData ) и любая программа которая умеет обрабатывать хмл этой фабрики может читать и генерить файлы обмена совместимые с КД-3, если мы берем не файл а отдельную базу 1с и пишем на ней сервисы которые работают в соотвествии с форматом EnterpriseData то она будет совместима с КД-3

https://its.1c.eu/db/metod8dev#content:5851:hdoc

(128) КД-3 больше к МДМ. А шина должна уметь сообщение, принятое от отправителя, преобразовать в формат, понятный получателю. Включая мэппинг данных.
Т.е. то, что сейчас, например, вшито в виде регистра сопоставления в отправителя и получателя - это кусочек шины.

(130) МДМ - межделмаш?

(128) КД2 к шине отношение имеет такое же, как давление в шинах авто к степени компрессии в цилиндрах того же авто.

(132) где я писал про КД-2?
(130) вся фишка КД-3 это единый стандарт EnterpriseData, именно он обеспечивает понятность данных любой системой которая его поддерживает.

(133) Я очепятался, имел в виду 3

(133) Это стандарт некоторого подмножества конфиг на 1С. А в мире, к счастью, кроме 1С ещё много других платформ.

Лучше бы глюки кэширования ликвидировали. А то правишь внешний отчет на СКД, а он открывается старый. Приходится менять или имя отчета или имя варианта. Бесит реально. Вместо этого занимаются хренью какой-то "в стиле лофт".

enterpricedata хорош для обмена между конфигурациями 1с.
из другой системы,часто,проще выгрузить данные в фррмате,необходимом для загрузки в конфигурацию 1с без преоьразования,чем костылить преобразование во что-то,что потом прнобразовывается в данные конфигурации.

Я так понимаю 1С Axelot'а опустила полностью.

(137) А 7-ку enterpricedata проглотит - выгрузку кое-чего из ТИС 7.7 в БУХ 8.3 ?

(138) Ну почему, они все еще могут продавать свою шину, как решение для обменов со своими конфами, к примеру, теми же WMS/TMS. Например, в WMS 3, "нормального" обмена по сути не было, чтобы работал "из коробки", все обычно пишут свой.

(127) Что такое "справочная база"? У нас вообще только 1 база.

Развитие средств интеграции очень важно для 1с, коль уж 1с пытается окучивать крупный бизнес

(139)
http://catalog.mista.ru/public/791366/
http://catalog.mista.ru/public/570415/
...

Это типа RabbitMQ с возможностью сразу прикрепить файл?
Или еще доп.преобразователь данных? (там пишут о каких-то расширениях)

Кто тестил? Расскажите.

(141) Master Data Management