Спасибо за наводку, поизучаю, если будет что-то, что можно применить на практике - сделаем статейку.
Что касается категоризации отечественных ESB-решений, я всё же не вижу в ней большого смысла. Рынок микроскопический, живых решений - по пальцам пересчитать, рук хватит.
Под живыми решениями я имею в виду какой-то продукт, а не опыт запустить интеграцию на open source у нескольких заказчиков. Продукт, где вендор имеет регулярный релизный цикл, занимается развитием продукта, а не тушением пожаров на проектах, да и в целом делает продукт для интеграций, а не для решения какой-то задачи внутри другой системы. Нужно смотреть на объективные факты, а дополнительная классификация от Сергея Скирдина, пусть даже сделанная на основании ГОСТа, практической пользы не даст.
Спасибо за комментарий. На самом деле обзоры оказались делом вполне благодарным 🙂 На профильных мероприятиях люди подходят, благодарят и за статьи, и за чат «Шины не для машины» - это очень приятно.
По классификации продуктов есть сложность - четкого общепринятого стандарта вроде ISO, по которому можно без споров разделить такие решения на MQ, ESB, DMP и т. д., нету, либо я такой не встречал. Границы размыты, а значит моя оценка будет субъективна. В обзорах я старался избежать субъективизма - дать максимум информации о продуктах, чтобы читатели сами могли сделать выводы. Там где вендор позиционировал решение как платформу, я так и писал, а брокером, кстати, себя никто не назвал 🙂 Делать из этого классификацию смысла не вижу, за небольшим исключением все назовут себя платформами, какой прок от этой классификации?
Я согласен, что основной объем тестирования идет именно на 1с. Выбор Jenkins, Allure понятен. На Vanessa automation мы тоже смотрели, но не придумали как передавать артефакты между процедурами записи и получения.
Для записи скорее всего аналитик накликивает сценарий, а вот как по этому сценарию сделать проверку, мы не придумали. У вас получилось?
Мы в итоге остановились на разработке своего фреймворка для тестирования интеграции. Python, с 1С взаимодействие идет через ODATa, отчеты в Allure.
Kdiff очень специфический инструмент. Я его пробовал, лет 8 назад, и он мне не зашел. Может конечно что-то поменялось с тех пор, но на тот момент использовать его имело смысл только если постоянно занимаетесь обновлениями.
В принципе у людей оперативный учет ведется в УПО и оперативные данные там и должны учитываться (фактически отработанное время, премирование, депремирование, различного рода компенсации), далее по регламенту (ежедневно, раз в неделю или раз в месяц в зависимости от задач) грузиться в ЗУП там их обработка и должна происходить. Все остальное в ЗУП там для этого все есть.
Именно так и реализовано. УПО считает свою часть, ЗУП считает свою часть.
Заголовок статьи громкий, заглянул думал может какую интересную историю почитать, но всю статью можно было бы изложить в пару строк - "Мы молодцы навели порядок там где был бардак". Для этого статья не нужна была, потому что обычная ситуация, коих тысячи.
Хабр читают не только ИТ-шники, но и те кто управляет таким бардаком. Цель статьи - показать, что может быть по-другому.
ЗУП хорош для кадровиков и расчетчиков. Для мидл менеджмента в кофейнях он сложноват, им нужен максимально простой и понятный интерфейс учета рабочего времени. Табель в ЗУП простым никак не назвать.
ED включает в себя правила записи и чтения объектов 1с в универсальном формате, а так же план обмена для регистрации объектов, регистры для сопоставления объектов и транспорт, который Вы указали. В адаптере датареон используются только правила (причем в датареоне можно их дополнять и изменять, не делая расширений и не меняя основную конфигурацию).
Регистрация объектов производится через стандартные механизмы датареон. Сопоставление объектов через банк данных датареон (прослойка между шиной и базой данных). В качестве транспорта - датареон.
Встроенный транспорт работает с точка - точка интеграциями. Использование датареон в качестве транспорта позволяет читать объект один раз из источника и отправлять в множество приемников с гибкой маршрутизацией и, при необходомости трансформацией, обогащением сообщений.
Датареон точно не BPM. Система управления бизнес-процессами не может существовать без интерфейса взаимодействия с пользователями - участниками процесса.
Также модуль хранения данными не является заменой СУБД. Это прослойка к СУБД, позволяющая работать с БД, не особо заботясь об ее устройстве (создании таблиц, реструктуризации и т.п.), плюс возможность работать с СУБД в терминах объектной модели (типов данных, созданных в Датареон), записывать, читать, искать объекты в БД.
Отвечая на ваш вопрос о бенефитах такого сочетания, точно могу отметить: сочетание ESB + БД очень удачно отражает широко распространенное ожидание от ESB. Про ESB принято думать, что это такая штука, которая стоит посередине информационной системы, и все системы с ней связаны (и это правда), а еще, раз все из нее берут данные, то она и есть центр правды, и где-то в ней хранится золотая запись справочника номенклатуры и корректные данные о вчерашней выручке. Этого в ESB нет: выручка хранится в КХД, а золотая запись - в МДМ.
Но, тем не менее, есть масса кейсов удачного сочетания ESB + модуль хранения данными:
· данные о сопоставлении объектов информационных баз; · кеш данных для приложения / личного кабинета / сайта, когда все данные лежат в 1С, но 1С не готова отдавать их 24/7; · формирование сырого слоя для КХД.
В среду в 8:30 решил закинуть денег на open ai api. Оплатил и написал в их чат продавцу. В обед зашел в чат - тишина. Написал в саппор. В 18 с чем-то продавец ответил о чем я узнал от саппорта, потому что из беседы на сайте уведомления никуда не приходят.
Я тут же зашел и продолжил переписку, но ответа снова не последовало.
В четверг снова написал в саппорт, и написал продавцу свой телеграмм, для оперативной связи. К концу дня продавец вышел на связь, с горем пополам зачислили деньги на баланс.
Печально, что родители не научили Вас культурно общаться. А еще, раньше за хамство можно было сразу по лицу получить, а теперь можно назваться лешим и писать что угодно в Интернете. Такие времена.
Смысл шутки в том, что для каждой задачи есть свой инструмент. Если вам нужно супербыстро переносить много документов, не нужно использовать ни КД2 ни КД3, напишите просто код выгрузки и загрузки. При грамотном подходе работать будет в разы быстрее любого готового протокола.
— Возьмите шуруповерт, вам с саморезами будет значительно легче работать. — Ага, покажите, как он гвозди забивает!
Если серьезно, ED конечно, не умеет переносить движения. Возможно пока. И для переноса большого количества документов тоже не годится, слишком большой оверхэд накладывает универсальность.
Вообще, я ED не сильно люблю, как и всякий чужой код. Я когда начинал работать с 1с, была семерка, и там проще было за выходные конфу с нуля написать, чем что-то готовое допиливать. Но сейчас реалии другие, 1с стала гораздо сложнее (по объективным причинам), труд программистов дороже. Предприятия просто не хотят переплачивать за разработку того, что уже сделано, проверено, протестировано. В ответ на этот запрос и родился продукт - дополнение к датареон для настройки интеграции с использованием формата Enterprise Data.
Датареон система промышленного уровня, применяется на больших проектах.
Если у вас задача соединить две базы, очень редко нужна шина. А если их 5-10-25-80 шина помогает:
Отправлять объект из одной базы в несколько
Собирать все ошибки в одном месте
Решает вопрос с хранением очереди, если одна из систем ушла на обслуживание
Делать интеграции проще: нужно только написать код извлечения данных из 1с и помещения данных в другую 1с. Очереди, коннекторы, логирование - все уже написано, проверено, поддерживает многопоточность и другие фишки из коробки.
Мой стаж в ИТ без малого 30 лет. Я никогда не сидел без работы, у меня даже резюме никогда не было. Я не очень понимаю идею безусловного дохода в ИТ, зачем? Я бы не хотел, чтобы мои дети получали безусловный доход.
Пенсия, родители, какие-то проблемы со здоровьем, это да, требует поддержки.
А что в этом плохого? Рост производительности труда всегда хорошо для экономики. Если за рабочие места переживаете, то кажется не время. В ИТ уж точно огромный кадровый дефицит.
Александр, добрый день!
Спасибо за наводку, поизучаю, если будет что-то, что можно применить на практике - сделаем статейку.
Что касается категоризации отечественных ESB-решений, я всё же не вижу в ней большого смысла. Рынок микроскопический, живых решений - по пальцам пересчитать, рук хватит.
Под живыми решениями я имею в виду какой-то продукт, а не опыт запустить интеграцию на open source у нескольких заказчиков. Продукт, где вендор имеет регулярный релизный цикл, занимается развитием продукта, а не тушением пожаров на проектах, да и в целом делает продукт для интеграций, а не для решения какой-то задачи внутри другой системы. Нужно смотреть на объективные факты, а дополнительная классификация от Сергея Скирдина, пусть даже сделанная на основании ГОСТа, практической пользы не даст.
Александр, добрый день!
Спасибо за комментарий. На самом деле обзоры оказались делом вполне благодарным 🙂 На профильных мероприятиях люди подходят, благодарят и за статьи, и за чат «Шины не для машины» - это очень приятно.
По классификации продуктов есть сложность - четкого общепринятого стандарта вроде ISO, по которому можно без споров разделить такие решения на MQ, ESB, DMP и т. д., нету, либо я такой не встречал. Границы размыты, а значит моя оценка будет субъективна. В обзорах я старался избежать субъективизма - дать максимум информации о продуктах, чтобы читатели сами могли сделать выводы. Там где вендор позиционировал решение как платформу, я так и писал, а брокером, кстати, себя никто не назвал 🙂 Делать из этого классификацию смысла не вижу, за небольшим исключением все назовут себя платформами, какой прок от этой классификации?
Я согласен, что основной объем тестирования идет именно на 1с. Выбор Jenkins, Allure понятен. На Vanessa automation мы тоже смотрели, но не придумали как передавать артефакты между процедурами записи и получения.
Для записи скорее всего аналитик накликивает сценарий, а вот как по этому сценарию сделать проверку, мы не придумали. У вас получилось?
Мы в итоге остановились на разработке своего фреймворка для тестирования интеграции. Python, с 1С взаимодействие идет через ODATa, отчеты в Allure.
Поделитесь практическим опытом, как на проекте внедрения КШД организовать непрерывное тестирование? Какие инструменты используете?
Kdiff очень специфический инструмент. Я его пробовал, лет 8 назад, и он мне не зашел. Может конечно что-то поменялось с тех пор, но на тот момент использовать его имело смысл только если постоянно занимаетесь обновлениями.
В смысле промпт длинный или статья?
Если про статью речь, так там в начале специально написал, кому нужен результат, мотайте в конец.
Именно так и реализовано. УПО считает свою часть, ЗУП считает свою часть.
Хабр читают не только ИТ-шники, но и те кто управляет таким бардаком. Цель статьи - показать, что может быть по-другому.
ЗУП хорош для кадровиков и расчетчиков. Для мидл менеджмента в кофейнях он сложноват, им нужен максимально простой и понятный интерфейс учета рабочего времени. Табель в ЗУП простым никак не назвать.
ED включает в себя правила записи и чтения объектов 1с в универсальном формате, а так же план обмена для регистрации объектов, регистры для сопоставления объектов и транспорт, который Вы указали. В адаптере датареон используются только правила (причем в датареоне можно их дополнять и изменять, не делая расширений и не меняя основную конфигурацию).
Регистрация объектов производится через стандартные механизмы датареон. Сопоставление объектов через банк данных датареон (прослойка между шиной и базой данных). В качестве транспорта - датареон.
Встроенный транспорт работает с точка - точка интеграциями. Использование датареон в качестве транспорта позволяет читать объект один раз из источника и отправлять в множество приемников с гибкой маршрутизацией и, при необходомости трансформацией, обогащением сообщений.
Датареон точно не BPM. Система управления бизнес-процессами не может существовать без интерфейса взаимодействия с пользователями - участниками процесса.
Также модуль хранения данными не является заменой СУБД. Это прослойка к СУБД, позволяющая работать с БД, не особо заботясь об ее устройстве (создании таблиц, реструктуризации и т.п.), плюс возможность работать с СУБД в терминах объектной модели (типов данных, созданных в Датареон), записывать, читать, искать объекты в БД.
Отвечая на ваш вопрос о бенефитах такого сочетания, точно могу отметить: сочетание ESB + БД очень удачно отражает широко распространенное ожидание от ESB. Про ESB принято думать, что это такая штука, которая стоит посередине информационной системы, и все системы с ней связаны (и это правда), а еще, раз все из нее берут данные, то она и есть центр правды, и где-то в ней хранится золотая запись справочника номенклатуры и корректные данные о вчерашней выручке. Этого в ESB нет: выручка хранится в КХД, а золотая запись - в МДМ.
Но, тем не менее, есть масса кейсов удачного сочетания ESB + модуль хранения данными:
· данные о сопоставлении объектов информационных баз;
· кеш данных для приложения / личного кабинета / сайта, когда все данные лежат в 1С, но 1С не готова отдавать их 24/7;
· формирование сырого слоя для КХД.
Ggsell ужасный сервис.
В среду в 8:30 решил закинуть денег на open ai api. Оплатил и написал в их чат продавцу. В обед зашел в чат - тишина. Написал в саппор. В 18 с чем-то продавец ответил о чем я узнал от саппорта, потому что из беседы на сайте уведомления никуда не приходят.
Я тут же зашел и продолжил переписку, но ответа снова не последовало.
В четверг снова написал в саппорт, и написал продавцу свой телеграмм, для оперативной связи. К концу дня продавец вышел на связь, с горем пополам зачислили деньги на баланс.
в общем, неудачный опыт, никому не рекомендую.
Печально, что родители не научили Вас культурно общаться. А еще, раньше за хамство можно было сразу по лицу получить, а теперь можно назваться лешим и писать что угодно в Интернете. Такие времена.
Смысл шутки в том, что для каждой задачи есть свой инструмент.
Если вам нужно супербыстро переносить много документов, не нужно использовать ни КД2 ни КД3, напишите просто код выгрузки и загрузки. При грамотном подходе работать будет в разы быстрее любого готового протокола.
— Возьмите шуруповерт, вам с саморезами будет значительно легче работать.
— Ага, покажите, как он гвозди забивает!
Если серьезно, ED конечно, не умеет переносить движения. Возможно пока. И для переноса большого количества документов тоже не годится, слишком большой оверхэд накладывает универсальность.
Вообще, я ED не сильно люблю, как и всякий чужой код. Я когда начинал работать с 1с, была семерка, и там проще было за выходные конфу с нуля написать, чем что-то готовое допиливать. Но сейчас реалии другие, 1с стала гораздо сложнее (по объективным причинам), труд программистов дороже. Предприятия просто не хотят переплачивать за разработку того, что уже сделано, проверено, протестировано. В ответ на этот запрос и родился продукт - дополнение к датареон для настройки интеграции с использованием формата Enterprise Data.
Датареон система промышленного уровня, применяется на больших проектах.
Если у вас задача соединить две базы, очень редко нужна шина. А если их 5-10-25-80 шина помогает:
Отправлять объект из одной базы в несколько
Собирать все ошибки в одном месте
Решает вопрос с хранением очереди, если одна из систем ушла на обслуживание
Делать интеграции проще: нужно только написать код извлечения данных из 1с и помещения данных в другую 1с. Очереди, коннекторы, логирование - все уже написано, проверено, поддерживает многопоточность и другие фишки из коробки.
В основном да, это данные из тех. журнала, но не только. Так же используются данные расширенных событий СУБД и консоли кластера.
"Скулевик" обычно не нужен, так как то что касается 1С на СУБД можно поправить своими силами, там не требуется каких-то специфичных знаний.
А вот 1С ник действительно скорее всего понадобиться, т.к. зачастую придется править кривой код и переписывать неоптимальные запросы в конфигурации.
Если своих спецов нет, можем предоставить.
Имена таблиц переводятся в термины метаданных, просто для этого они должны быть загружены, чего на момент скриншота еще не было сделано.
Так внизу есть вкладка 1С там отображается текст запроса в терминах метаданных 1С если они загружены.
Обращайтесь к нам, все расскажем
https://белыйкод.рф/contacts/
Мой стаж в ИТ без малого 30 лет. Я никогда не сидел без работы, у меня даже резюме никогда не было. Я не очень понимаю идею безусловного дохода в ИТ, зачем? Я бы не хотел, чтобы мои дети получали безусловный доход.
Пенсия, родители, какие-то проблемы со здоровьем, это да, требует поддержки.
А что в этом плохого?
Рост производительности труда всегда хорошо для экономики.
Если за рабочие места переживаете, то кажется не время. В ИТ уж точно огромный кадровый дефицит.