РИБ была создана в те времена, когда с интернетом были напряги, данные носились туда-сюда на флешках. Отсюда и эти контроли номеров сообщений в РИБ.
Однако с той поры много воды утекло.
Хотя РИБ по прежнему применяется там, где могут быть перебои с интернетом (в магазинах, например).
Недавно мне пришло озарение - а ведь РИБ морально устарело.
Теперь достаточно другой схемы.
Регистрировать нужно просто измененные объекты, без номеров сообщений.
При установлении сообщения измененные данные в виде потока JSON/XML сразу записываются в базу-получатель, при этом регистрация сразу же удаляется в базе-отправлител.
Очень просто и надежно.
И нет таких блокировок при выгрузке, как в РИБ.
Пора бы 1С поддерживать в платформе и такой АНТИ-РИБ.

Немного лирики: в 2013 где-то я заменил типовой РИБ обмен в базе из 100 точек РИБ на свой собственный, где как раз не было номеров сообщений.
Но это все же была еще не та схема, о которой сейчас веду речь.

Еще немного более ретро-лирики: в 2008 году разрабатывал схему обмена, так мой начальник-программист все пенял, что какую схему я не принесу,
все РИБ получается. А я не мог понять, чего он хочет. Теперь понимаю, что он, возможно, хотел эту схему.

Которую я дарю вам.

это называется "сервисная шина"

Щедрость его не знала предела...
РИБ это ещё и синхронизация конфигураций.

1С скоро нам её подарит https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/

Но многие используют DATAREON ESB (корпоративная сервисная шина данных)
Совместимо с 1С

(0) я помню твои танцы с бубнами, когда данные терялись
а транзакционную целостность кто обеспечит?
шина не исключает номеров пакетов

А че там компонента уже готова и захватила рынок?

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

(0) Как же ты далек от реально крупных проектов...

(0) КД2 и КД3 ты уже освоил?

(0) автор дочитал книжку Радченко до главы про обмен без квитирования?

(3) не умеешь программно обновлять конфы? Тогда мы летим к вам.

(2) (4) не думаю, что там прям будет альтернатива РИБ.

(6) транзакционная целостность - это для параноиков.

(8) прерывания не мешают работе схемы. После прерывания докачиваются остальные данные, а не начинается сначала, как в РИБ

(10) КД2 - давно, КД3 (который могильщик КД2) не интересует

(11) не, не читал, но не осуждаю. Книжки это хорошо, где практика?

(14) ясно понятно. Поэтому ты теперь свободный никем не признанный художник?

(0) "При установлении сообщения измененные данные в виде потока JSON/XML сразу записываются в базу-получатель, при этом регистрация сразу же удаляется в базе-отправлител."  - я бы добавил "Если при загрузке возникли ошибки, с регистрации данные в базе-источнике не снимать".  В целом: для определенного круга задача вполне рабочая схема.

(5) Не поминай всуе...

(19) Весьма. Но многие до сих пор жуют РИБ, хотя я подобный механизм реализовывал еще в 2013. Вот сегодня озарило, что надо популяризовывать эту тему.

Кстати, у меня есть несколько клиентов на РИБ, может предложить им?

ИТС -> Главная -> Книги и периодика -> Технологии интеграции "1С:Предприятия 8.3" -> Глава 3. -> Универсальный механизм обмена данными.

Опасаюсь, что ТС прочитает еще что-нибудь по обменам. Тогда половина веток будет его авторства.

+ (23) С такой же степенью полезности.

(15) база-отправитель как узнает что даннеые база-получатель получила и докачала спустя полтора суток перерыва?

Номера пакетов - это вариант квитирования. без квитирования - вариант в общем случае неработоспособен. Другое дело что в большом количестве случаев можно обойтись без квитирования. Но не во всех.

(25) у базы-отправителя прямой коннект, йо. Она передает по веб-сервису по-объектно. Ну или пачками по N

(26) в 99%

(26) вот что забавно, в 99% случаев, где используется РИБ можно обойтись без квитирования, но используется морально устаревшая РИБ, не странно ли?

(23) 0 бит, прости

(28) возможно в какой-то отрасли. в других вариантах - 99% с квитированием надо. Теперь вопрос. если даже в 1% случаев надо квитирование - как твоя универсальная схема без квитирования будет работать?

(30) Видишь ли, Геня, народ уже давно трактует твое "0 бит" как "Геня понял 0 бит из рассказанного ему". Продолжай, пожалуйста.

(31) там где надо квитирование будет применяться риб или моя схема с квитированием. Она его не исключает, если ты пожумаешь

(33) чем твоя схема с квитированием принципиально отличается от РИБ?

(34) ну моя схема без квитирования увщето.
Но квитирование можно прикрутить.
Моя схема не использует файлы, обмен идет пообьектно, как обьект передался, регистрация о нем удаляется

(35) а как ты узнаешь что объект передался? если тебе принимающая система не даст ответ"ок, обьект принят, записан в получатель". Или ты считаешь, что отправил запрос на базу-получатель =это равно что "объект успешно передался".?

Rabbit MQ, AMPQ и прочие подобные термины гениям, похоже, не знакомы...

(36) Геня настаивает, что физическая передача === прикладной обработке данных. Тем самым весьма явно демонстрируя свой уровень понимания.

ТС видимо до сих пор не понял, что обмен в РИБ это частный случай обменов. Когда структура данных, которые участвуют в обмене идентична в отправителе и в приемнике. В общем случае это не так. И что служба регистрации изменений может существовать независимо от РИБ.
И что транспорт передачи != данные... И что иногда нужно отправить из системы в систему например отчет по данным, которых в приемнике вообще не существует.
И что люди уже давно придумали и пользуются обменом (например) с сайтом. Со службой регистрации изменений. Но без всяких РИБ.

В общем нам еще предстоит много серий дешманской комедии под общим названием "мой гений дарит вам".

(38) ы/===/is

(16) >КД3 (который могильщик КД2) не интересует

Какая-же чушь.

План обмена без риб. С обвязками кд2 по моему на все случаи жизни.

(42) не совсем но КД3 ее прям неплохо так дополняет.

(0) велосипедист фигов. Угомони уже свой ларёчный гений и ради расширения кругозора поучаствую в большом проекте

(39) 0 бит, КЭП. Все это давно известно. Но люди по-прежнему используют РИБ. А зря.

(45) 0 бит - это твой новый ник?

(43)как я понял кд3 только для несильно изменённый типовых. Т. Е. На фиг не нужна грубо говоря.

(47) да, это очередной квадратно-гнездовой велосипед от 1С. Видишь, "большие дяди" типа Конструктора считают ее жизненно необходимой для "больших проектов". На самом деле нет.
Я уже писал, что в новых релизах типовых КД2 не поддерживается, т.е. нельзя на ней наваять обмен по плану обмена. Как мне объяснили из-за безопасности во фрешах, т.к. КД2 может выполнять любой код. В общем, опять простота принесена в жертву безопасности. И все это под маркой "прогрессивной КД3".

(46) КЭП, переставай оффтопить в тематических ветках. Создай уже себе ветку ненависти к Гению 1С, там я тебя буду периодически подкармливать (отвечать). ;-)

(48)в типовых идея наверное имеет смысл. набор сущностей ограничен можно наверное впихнуть их в заранее оговореный формат. И грузить выгружать в из него.
Для измененых конф это слабо подходит.
С кд2 Можно использовать универсальный обмен обработку там есть планы обмена.

(48) КД2 сильно тормозная. Для ларьков только. Поэтому фирма 1с её и выпилила

Кстати, обмен через планы обмена работает намного бцстрее. XML на несколько гигов прогружает за минуты. КД2 на таких объемах уходит в себя на дни, и может не вернуться

(51) Ну какбы не сама кд2 тормозная, а типовая реализация тормозная.

(48) на сколько помню в кд3 есть РС где хранится xml обмен, которую можно заменить на свой кд2 xml

(51) выпилила, а что взамен? не универсальная КД3? Если КД2 у вас тормозит, значит вы ее плохо готовите.

(50) Вот кстати да, они бы еще на CommerceML обмен перевели. Велсипедостроители

(53) Плохому конструктору всегда Кады2 мешают.

"КД2 не поддерживается, т.е. нельзя на ней наваять обмен по плану обмена" ЦЫ(48)

При этом ТС глубоко фиолетово на тот факт, что план обмена это основа службы регистрации изменений. Без этого невозможно организовать обмен только изменившимися данными. Хоть с применением КД любой версии, хоть в РИБ, хоть в общем случае произвольный обмен.

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

(0)

Немного лирики: в 2013 где-то я заменил типовой РИБ обмен в базе из 100 точек РИБ на свой собственный, где как раз не было номеров сообщений.


Помним-помним как тебя потом выставили за дверь и добавили в ЧС в куче контор.
С тех пор ты то и нормальную работу найти не смог - поэтом практикуешь тут теперь гештальт-терапию.

(59) обмен без квитанций? А танцевать на минном поле он не пробовал?

(55)чего тебе не хватает в КД3?

(55) а если не тормозит, то ты работаешь с маленькими объемами данных...

(62) универсальности

(58) рс не катит, не? Ггг

(64) да куда уж универсальнее?

(65) Остап Сулейманович утверждал что "кому и кобыла невеста" Так что таки да - гы-гы.

(67) Это Остап не утверждал. Это дворник утверждал.
Не надо картавить классику

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

И самое главное,что номера сообщений,особенно,если их не чистить,позволяют отслеживать передачу в несколько вариантов.
Основная проблема обмена - это восстановление резервной копии,когда одну базу восстановили,а вторую нет,и,если мы хранили номера сообщений от последнего бэкапа,то мы просто их передаём (сразу напомню,что стандартный механизм этого не умеет).
Если же нет,то мы огребаем проблемы необходимости синхронизации баз.
А когда все работает,можно и вообще не отслеживать,записалось или нет,а просто незаписанные в лог писать-вме равно,если объект один раз не записался,то повторение попытки его записи,обычно,бессмысленно.

Основное отличие кд2 от кд3 в том,что последняя предлагает набор универсальных объектов,и сама передача данных идёт через них,а на двух сторонах делается преобразование в или из определенного объекта.
В кд2 же свобода разработчика и последний выбирает что и где преобразовывать,в результате,если два разработчика написали два обмена,то объединить их намного сложнее,чем написать заново - в кд3 предполагается,что это не так.

(64) сдаётся ты не знаешь КД3 от слова совсем

(70) точнее так: обмен типовых придётся при изменении одной конфы менять только с одной стороны (если конечно нет цели расширить сам обмен)

*типовыми = между любыми

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

(69) вот видишь, как сложна жизнь параноиков. Практика показывает, что в реальных базах достаточно просто признака, что объект был изменен, без квитирования

(74)поспорил-бы но влом и один хрен ты не знаешь КД3, так что не вижу смысла

(76) дешевая гуру-манипуляция

(0) >Очень просто и надежно.

Данные тезисы чем-то обоснованы, или следуют непосредственно из гениальности автора?

Чем предполагается обеспечивать надежность, не распределенными транзакциями, кои есть антоним простоты?

(0) для киоска покатит

(78) ты просто схему посмотри и сам поймешь, там нечему ломаться.
(79) Да, ГУРУ

Есть ещё более гениальный ход - после завершения транзакции изменения сразу передавать объект,тогда вообще ничего регистрировать не нужно.
Но,если обмен не прошел,то что делать?

(81) он же уже писал - для киосков - и так сойдет

(74) как всё запущено... Лучше бы твой гений документацию почитал, чем лисапеды изобретатьй

(80) если тебя за такие поделки увольняли - ты тупо подставляешь других.

(80) Была бы схема, я бы посмотрел.

(81) ну в моей схеме обмен сеансовый, когда есть интернет. Так что "без фанатизама" плиз.
(82) Но не аргументировал.
(83) О да, ГУРУ БОЛЬШИХ ВНЕДРЕНИЙ. ;-)
(84) Меня увольняли три раза в жизни и ни разу не объяснили почему, так что хз.
(85) У меня кстати осталась обработка обмена 2014 года вроде, счас гляну.

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

(85) https://yadi.sk/d/sv-8ZwH_ngn1Ww (вот обработка 2015 года), там пара функций в общем модуле САП, но они примитивны. Логику понять можно, если интересно. Она даже CF обновляла. Вот так! ;-)

Но решение 15-го года не такое, как я предлагал, там какая-то своя хитрая схема, суть ее забыл, можете восстановить обратным инженирингом. ;-)

А, вот нашел и описалово: https://yadi.sk/i/NelUpggm6Hwm3g

2008 год - http://catalog.mista.ru/public/16687/

полная поддержка транзакций и квитирования

изначально делалась вообще для 7.7

кое где работает до сих пор...

Вы лучше скажите как в ваших обменах реализована следующая логика:

Есть Документ и в нем есть реквизит, например, Склад - по нему определяется в какой узел он уходит

Внесли документ со складом "Вологда" - он туда ушел
Позже поняли ошибку и поменяли в нем склад на "Кострома" - он ушел в новый узел
Требуется чтобы этот документ либо пометился на удаление, а лучше был удален из узла "Вологда"

(92) А планы обмена тут ни причём. Тут логика регистрации. Ну и карательные расстрелы на 10 лет без права переписки.

(93) понятное дело, что логика, но бывает всякое
мне кажется самое простое решение:
в текущем документе не менять Склад, а пометить к удалению объект - он пометится в старом узле
скопировать, выбрать новый склад, провести - он уйдет в новый узел

(94) подчиненность ломается

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

(94) если для системы это критично, то можно регистрировать удаление объектов, почему бы и нет.

Критично = часто встречается, сложно исправлять руками

+(96) но если уже есть ссылки на данный документ?

И тут люди начинают понимать,что передавать нужно не документ,а состояние базы,то есть несколько справочников и документов вместе.
Да и вообще,подход 1с здесь кривой,так как она не умеет делать ссылки на поля другого объекта,в принципе.
То,что есть какие-то подчинённые документы,в данной логике не сильно спасает,если мы меняем реквизит одного документа,то в подчинённых тот же самый реквизит должен меняться.
Только вот перемещения могут идти по цепочке складов,и изменение конечного склада - это новая цепочка.
Так что,обмен,сам по себе,какой бы он не был,это просто обмен,а если есть зависимость от бизнес-логикт,то тут в любом случае будет нестандартно.
Ну и,самое главное,что передача документа смысла не несёт,особенно,если из связанных документов один будет передан,а другой - нет.
Ну и в примере,отгрузка с одного склада - в корне просто заказ,в котором склад,в подчинённых перемещения,наряды на отгрузку и т.п.то есть совершенно другие документы,а нужно ли сам заказ передавать?да и потом проще ему статус ОТМЕНА передать,чем пометку удаления и т.п.

И ещё одна причина,когда нужен номер сообщения - по нему мы смело можем сказать сколько раз выполнялся обмен,а если номера нет, то на этот вопрос быстро и просто не ответить.
С точки зрения накладных расходов наличие только записи объект,узел или наличие записи объект,узел,номер сообщения не сильно различается.