Приветствую, Форумчане!
У нас много разных 1с конфигураций: ЙЕРП, БП, ЗУП, ДО, УАТ
И вот кто-то предложил организовать обмен (синхронизация) данными между этими конфигурациями по некоторым справочникам:
- контрагенты
- партнеры
- договоры
- подразделения
- склады
- сотрудники
- физлица
- должности
- номенклатура
В качестве инструмента предложили 1С: Шина
Поделитесь своим мнением по этому инструменту. Неужели он так хорош, как говорит реклама от 1с?
бегло пробежался по информации: писать кода не меньше, чем при других обменах, также требуются планы обмена, вс-сервисы, хтдо объекты... Пока не увидел мега преимуществ.
А как Вы себе его представляете? Что он такое для Вас? Какие он должен решать Ваши проблемы?
Суть: шина - это транспорт. В 1С есть "сервисы интеграции", которые умеют работать с шиной. О них тут один товарищ написал множество интересных статей. Там нет внутри конвертации данных, там нет внутри сопоставления А и Б, там только доставка пакетов с данными, которые отправляются одной системой другой системе. Это может быть интересно в плане мониторинга, контроля движений данных, гарантии доставки пакетов с данными. Народ все это делает через файлы, фтп, веб-сервисы, даже яндыкс-диски. И вроде бы работает. Но удобно посмотреть, что куда ушло, дошло, пришло - этого без шины чуть сложнее.
(21) Так и ESB уже давно не новость. BizTalk - 24 года, например.
Давно уже описаны основные элементы интеграции https://www.enterpriseintegrationpatterns.com/ Т.е. вы просто составляете свой шаблон интеграции и из него уже следуют инструменты.
Я вот в шине не увидел пока "Canonical Data Model", хотя она у 1С даже и есть.
P.S. И даже книжку можно стырить в VK, если найти через поиск по запросу "шаблоны интеграции корпоративных приложений"
(25) Не надо ёрничать. Надо относиться к делу чуть более профессиональнее и поддерживать чуть более высокий уровень дискуссии. Например уточнить задачу, обстоятельства, сроки и ресурсы. Хотя бы сделать вид, что Вас интересует решение проблемы и проблема вообще есть.
Но за версту виден праздный интерес. Не надо делать из сомнительного продукта IT-потеху, когда их, потех, и так достаточно.
можно и DATAREON применить. В целом - быстро научиться можно
Пока с 1С:Шиной не работал, не могу сравнить...
Подождите отзывов коллег обладающих таким опытом
(starik-2005)
Ну т.е. я в одной системе создаю контрагента "ААА", в другой системе создаю контрагента "ААА" и благодаря шине у меня в обеих системах появляются целых 2-а контрагента "ААА"?
Создаю номенклатуру "Кирпич красивый", а другой создает "Красивый кирпич" и получаю две одинаковые номенклатуры с отличием только в мировозрении на наименование со стороны разных пользователей?
Или всё таки можно что-то сделать, чтобы рубить дубли в шине? Или таки писать мегакод, который позволит после получения пакета сравнивать и если по каким-либо признакам получаем дубль, то ставить на удаление, предварительно проверив, а вдруг уже есть операции с этой номенклатурой?
Неа. Благодаря правилам конвертации.
Даже интересно становится, откуда такие у всех мысли о шине, как о чудомашинке, синхрионизирующей А и Б. Шина - это просто средство доставки пакета данных из А в Б. О содержании пакета шина ни бельмеса.
(6) Насколько я понял, шина 1С - это не только про транспорт, она может работать и транслятором, т.е. о содержании пакета в определенном смысле должна знать.
А вот почему некоторые считают шину заменой конвертации самому странно, при этом почему-то никто, например, не считает таковым тот же ftp, используемый для обмена сообщениями обмена.
Вообще же шина - это вещь, сильно облегчающая жизнь при обмене информацией в гетерогенной среде.
На порядок мощней, чем пытаться сделать велосипед на https.
Вот только далеко не всегда нужна полноценная ESB, да еще сильно платная, часто достаточно использовать простой брокер сообщений.
это не только про транспорт, она может работать и транслятором, т.е. о содержании пакета в определенном смысле должна знать
Ну а в чем смысл ее "трансляции"? Да, там можно что-то такое написать, но сложность никуда не девается, просто переезжает в другой продукт. И при любом изменении внешних систем придется что-то там в шине пилить. Зачем, если изменения касаются внешних систем, для которых уже существуют правила на КД?
Кстати, ETL - это больше для выгрузки в общие витрины DWH, а не для обмена классификаторами в "гетерогенной среде".
ЗЫ: мифологизация всех этих шин, очередей и прочего в современном ИТ говорит о том, что людей, которые покупают продукты не для решения проблем, а для старта очередного внутреннего проекта, становится все больше, а тех, кто в ИТ что-то понимает - все меньше.
DWH - это агрегатор, в который стекаются данные, а не из которого они валятся назад после обработки. Там четкий путь: обособленные информационные системы -> Data WareHouse (DWH).
Data Warehouse — это единое корпоративное хранилище архивных данных из разных источников (систем, департаментов и прочее).
Вообще, в корпоративной архитектуре при "грамотном подходе" (системно и все такое) формируются информационные системы, как сервисы. Вот, например, "мастер дата менеджмент", НСИ по-нашенски. И суть \то системы отделить точку входа нормативной информации от остальных систем, где информация очищается и валидируется, после чего поставляется остальным системам в одну сторону (в идеальном идеале). То же самое и с другими системами. розница/WMS/MES/... поставляет данные в бухню/ЕРП/УХ/... Назад при правильном подходе данные не едут. И шина является для этих систем транспортом. Да, там внутри можно привести к единым идентификаторам все эти пакеты сообщений, но если это пакет КД, то что-то сомневаюсь в целесообразности его преобразования внутри шины, бо трудоемкость оного граничит с трудоемкостью разработки правил вообще, ибо синхронизация - самое непростое, что там есть.
(17) Мне здесь чем-то не нравится - это да, есть такое. Чем - вот так прямо и не сказать. Может быть этим, о чем я в предыдущем посте в этой теме говорил:
... [тех кто] ... покупают продукты не для решения проблем, а для старта очередного внутреннего проекта, становится все больше, а тех, кто в ИТ что-то понимает - все меньше.
(17) Знаете, я тут понял, что "нейросеть" у большинства ИТ-шников оказалась переученной. Т.е. не той, которая "думает", а той, которая "выбирает правильный ответ". Т.е.. вот учатся все, сдают на сертификаты, а потом, такие, опа, правильный ответ - это ... Ну а там чем больше слов совпало, тем "более правильный" ответ получился. И вот вообще без понимания. Так что курсы окончательно убьют интеллект - там ведь только кейсы, а не про думать. Нейросети убьют интеллект окончательно. Ну будем посмотреть, что из этого выйдет.
Интеллект - это ведь способность решать задачи, при том такие, с которыми ты еще не встречался. Это на подумать, в отладчик зайти. Да, интернет сделал многие проблемы простыми, т.к. содержит ответ. Но ведь современные программисты даже вопрос сформулировать зачастую неспособны. И чем бальше в лес, тем больше такого. Я вот говорил, что поиск на инфостарте - такое себе, но ответ был какой: "Да все нормально у нас с поиском". Ну а что, ждать, что кто-то им всерьез займется? Он же как-то работат, что-то ищет. Ну как бы флаг в руки, барабан на шею...
Обучение куда тяжелей монетизировать чем набор копипасты. Обучение всегда связано с неприятным таким посылом, что покупатель чего-то не знает. А копипаста дает обманчивое, барское впечатление важности покупателя перед самим собой, что он хозяин, что именно он выбирает.
Покупатель тут идет платить за решение своей текущей проблемы. А если он, не дай бог, начнет учится, то он будет решать проблемы сам. И второй раз денег уже не принесет. И руководителя своего еще в этом убедит, на других подчиненненных повлияет, абонемент не купит, ну ужас же.
А дальше в действие просто вступает фактор времени. Накопленная масса копипасты начинает преть, найденные фрагменты решений уже напрямую не подоходят. Покупатели составляют из найденных ошметков своего личного, милого, но неработающего кадавра и гордо публикуют его. Общая масса преющей копипасты увеличивается, служа полупереваренным источником питания для других. Неучи берут куски этих кадавров у неучей, идет перекрестное опыление, инцест и как результат - вырождение когда-то великой королевской семьи.
Вменяемые давно посмотрели на все это и самоустранились. Можно помочь кому-то отдельному, персонально симпатичному, решить его отдельный кейс. Но симпатичных все меньше и меньше - инбридинг, он такой.
мифологизация всех этих шин, очередей и прочего в современном ИТ говорит о том, что людей, которые покупают продукты не для решения проблем, а для старта очередного внутреннего проекта, становится все больше, а тех, кто в ИТ что-то понимает - все меньше.
А это потому, что гренка не может стоить 8 долларов, а крутон - может. :)
Тема хайпа в IT слабо раскрыта. Если доживем, то лет через 5 услышим что-то типа "какая гадость эти ваши микросервисы с их оркестраторами оркестраторов", надо использовать "сосредоточенно/распределенные достаточно вероятностные AI системы", мы, правда, сами не понимаем, что это такое, но вам обязательно расскажем.
(9) Если вам необходим какой-то функционал шины, то вы его все-равно напишите.
Мониторинг обменов, например, очень непростая и недешевая задача.
И когда мониторинг показал, что в бухгалтерии "Авансовый отчет" без физлица, то что делать? Сколько надо всего знать, чтобы хотя бы приблизительно локализовать проблему? Много чего. Надо знать откуда получаем, что, как это конвертируется, как идет, всю цепочку в идеале. А у вас эта бухгалтерия одна из 50. А физлицо пришло из ЗУП, а авансовый из Комплексной, а комплексных с десяток :)
(4) Источником одного типа данных обычно является одна база данных, например, МДМ.
Уже оттуда настраивается отправка справочников в Шину, а она уже определяет движение данного пакета, добавка данных в пришедший, трансформация, отправка его в несколько получателей и т.п. в зависимости от потребностей и организации процессов управления данными
Если в наличии есть сильный айти отдел со скучающими от отсутствия серьезных задач красноглазиками и текущие интеграционные сервисы уже достигли пика и еле шевелятся то можно попробовать с прицелом на будущее опять же, если все устраивает и нормально работает то смысла нет
Ну что ж... наладил я эту то ли интеграцию, то ли обмен, то ли еще что-то в 1с: Шина.
Обмен односторонний ЕРП - Документооборот.
Использовал коды, которые нашел в интернете.
Обмен и обновление данными работает, но только если в базе исходнике и в базе приемнике реквизиты справочников полностью совпадают:
СправочникЗагрузки = Сред(Структураданных.Справочник, 15);
СправочникСсылка = Справочники[СправочникЗагрузки].ПолучитьСсылку(Новый УникальныйИдентификатор(СтруктураДанных.Ref));
//СправочникСсылка = Справочники.ФизическиеЛица.ПолучитьСсылку(Новый УникальныйИдентификатор(СтруктураДанных.Ref));
Если ОбщегоНазначения.СсылкаСуществует(СправочникСсылка) Тогда
СправочникОбъект = СправочникСсылка.ПолучитьОбъект();
Иначе
Если СтруктураДанных.Свойство("IsFolder") Тогда
Если СтруктураДанных.IsFolder Тогда
СправочникОбъект = Справочники[СправочникЗагрузки].СоздатьГруппу();
Иначе
СправочникОбъект = Справочники[СправочникЗагрузки].СоздатьЭлемент();
КонецЕсли;
Иначе
СправочникОбъект = Справочники[СправочникЗагрузки].СоздатьЭлемент();
КонецЕсли;
СправочникОбъект.УстановитьСсылкуНового(СправочникСсылка);
КонецЕсли;
ЗаполнитьЗначенияСвойств(СправочникОбъект, СтруктураДанных);
СправочникОбъект.Записать();
Показать
Обмен контролируется через УИД метаданных.
Я так понимаю, если нужны заполнения другими реквизитами, то нужно прописывать код для заполнения каждого справочника (документа), либо писать огромную таблицу (регистр сведений) соответствия реквизитов по аналогии визуального соответствия в "Конвертации данных".
Возникает вопрос и об дублировании информации. Например, добавляем в справочник "Должности" новую должность "Программист 2С", а такая должность уже есть в базе приемника. Значит после "обновления" нужно что-то предпринять, чтобы эти должности схлопнулись (есть такая обработка).
Еще хуже ситуация с предопределенными значениями и тем более с перечислениями (например "СтавкиНДС").
Ну если с перечислениями вроде понятно, тут только таблица соответствий, то с предопределенными дополнительные сложности.
Ну а так да, интересная ситуация. Достаточно просто указать в подписке на событие "При записи" новый объект для обмена и всё срабатывает. Если конечно достаточно тех совпадающих реквизитов.
Наверно как "плюс" можно указать, что обработку получаемых метаданных для интеграции можно писать в привычной среде программирования конфигуратора, используя уже знакомые в каждодневной работе методы, без изучения новых заморочек от "КД".
Дополнительная заморочка - контроль работы сервиса шины, который работает через браузер.
Не знаю как будет работать в другой схеме, у меня на локальной машине установлен Постгрес и все базы на нем. Обращение идет через:
http://127.0.0.1:9090/applications/InterERPtoDO-dev Насколько это будет стабильно работать в реальной системе и как настроить на реальном рабочем сервере с подключением к нему удаленных компьютеров - не знаю, не пробовал.
Говорят, что можно организовать двусторонний обмен, но не пробовал пока.
Как итог: продолжаю испытывать крайне радикальный пессимизм :-)
Каждая из этих баз, предположим, умеет к КД3 и есть общая для всех версия формата. Тогда шина поможет вам настроить обмен по топологии "звезда", а не "база-база", что снизит сложность с n! до n. Плюс единый центр управления и мониторинга.
А дальше возникают задачи по поддержанию единого формата обмена между всеми участниками системы и тут нам шина пока не друг, как я понимаю. Здесь мы уже должны как-то подключить КД3, которая будет рассылать обновления пакета схем всем одинаково и целая история с географией.
Т.е. если у вас нет человека с готовым планом интеграции систем, то не то что шина, вообще ничего не поможет.