Почему использование HTTP сервисов и данных в формате JSON - оптимальный выбор, вместо всех остальных вариантов при решении задачи обменов данными

17.04.20

Интеграция - WEB-интеграция

Личное мнение. Я выполнил за 2019 год 30+ интеграций разных систем.

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

Кто-то лепит обмены через COM, кто-то учит модные КД3, кто-то - использует крутых кроликов, а кому то навязали инновационную ESD.

У каждого решения есть свои плюсы и минусы. В таблице ниже свел воедино основные показатели самых распространенных инструментов и технологий.

Мой опыт в решении задач интеграции - это порядка 30 кейсов за последние 1 год. Хотя в отрасли я намного больше - просто не считал и не записывал кейсы ранее.

 

Оценки для решений

Все оценки даны для обмена справочником Номенклатура (из УТ в БП).

Оценки на "изучение" и "создание" я брал не по себе, а из наблюдений за своими сотрудниками.

Изучение   - оценка минимального времени в часах с момента знакомства до появления "понимания" как решать задачу

Создание   - оценка минимального времени в часах с момента знакомства до появления работающего решения

Доработка - добавление в обмен нового нетипового реквизита строкового типа

Скорость - оценка времени на одну итерацию обмена одним элементом справочника номенклатура

Объем данных -  влияет на скорость выполнения обмена. Для оценки трафика http выполнялось сохранение передаваемых данных в файл

Обмен с использованием КД2/КД3 выполнялся через файл.

* У вас будет вполне обоснованный намек о сравнивании теплого с мягким, но прежде чем об этом написать, дочитайте до конца)

Инструмент Изучение Создание Доработка Скорость Объем данных Аргументы за Аргументы против Комментарии
Выгрузка загрузка данных XML 0,5ч 0 0 Бесконечно 133 КБ Для разовой выгрузки между одинаковыми конфигурациями Для одинаковых конфигураций  
КД2 8 ч 3 ч 60 мин Бесконечно 127 КБ Много готовых решений и специалистов Сложно и медленно  
КД3 16 ч 3 ч 30 мин Бесконечно, но иногда быстрее чем КД2 115 КБ Если типовая 1с и есть компетенция Сложно и медленно Для нетиповых надо внедрять БСП
Rabbit 24 ч 8 ч 30 мин 1-5 сек 1 КБ Для серьезной нагрузки, быстрее всех Сложна в изучении. Часто - требует внешние компоненты  
Datareon 18 ч 5 ч 30 мин 1-5 сек 30 КБ Если есть много денег Сложна в изучении. Невероятно дикая система отладки С отладкой все печально
Kafka 7 ч 5 ч 30 мин 1-5 сек 1 КБ Для серьезной нагрузки Неведомый зверь  
COM 3 ч 3 ч 10 мин 1-5 сек ? -- Супер медленный. Платформо-зависимый.  
Http сервисы 3 ч 3 ч 5 мин 1-5 сек 1 КБ По совокупности показателей - лучшее решение Надо веб-сервер  
WEB сервисы 5 ч 3 ч 10 мин 1-5 сек 1 КБ -- Надо веб-сервер и подучить XDTO. Зачем, если есть Http сервисы?  

* КД = конвертация данных.

В сообществе описанные решения, обычно, носят нарицательное значение. Но не все это понимают, судя по комментариям.

Выгрузка загрузка данных XML. XML с сохранением в файл.
КД2. XML с сохранением в файл.
КД3. XML с сохранением в файл.
Rabbit. JSON без сохранения в файл.
Datareon. XML без сохранения в файл.
Kafka. JSON без сохранения в файл.
COM. Нативное кодирование без особых хитростей.
Http сервисы. JSON без сохранения в файл.
WEB сервисы. XML без сохранения в файл.

Понятно, что при желании данные, сформированные по правилам конвертации можно передать через HTTP сервис и такие решения уже встречаются. Но в данном случае  не рассматриваются.

Отдельно прокомментирую почему в обмене всего 1 элемент.

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

Выводы

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

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

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

По совокупности показателей - использовать решение с обменом через HTTP сервисы:

  • Максимально "нативный" код
  • Отсутствие необходимости долго учить инструмент
  • Отладка в виде обработки, не сложнее отладки печатной формы
  • Высокая скорость обмена данными

Приведенный выше пример в 1 сек для http сервиса, на самом деле занижен, потому что реальная скорость в десяток раз меньше при повторном выполнении.

Что остается неудобным в таком решении? Надо писать код, тогда как в конвертации данных иногда можно обойтись расстановкой галок.

Получается, что если скорость выполнения обмена на важна, задача - простая, то и КД подойдет :)

 

Вот 5 шагов, достаточные, чтобы написать свой быстрый обмен:

1. Установить веб-сервер

2. Создать http-сервис

3. Опубликовать базу 1с

4. Выучить методы, отвечающие за конвертацию в JSON и обратно.

5. Выучить методы, отвечающие за отправку данных по протоколу HTTP.

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

Через 3 часа чтения и нажимания кнопок - ты уже молодой специалист :)

 

Но даже в такой простой штуке можно найти подводные камни, то JSON не конвертируется, рушит платформу, то данные не доставляются, а то и задача вырастает до 3000 строк кода. Для решения таких сложностей существуют библиотеки и фреймворки.

Но об этом - в следующей серии.

http интеграция обмен

См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020    15747    10    17    

11

Интеграция 1С — Битрикс24. Обмен задачами

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс24. Разработка имеет двухстороннюю синхронизацию 1С и Битрикс24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (8.3.18.1289). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    17549    6    15    

13

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16360    42    49    

23

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25741    9    0    

7

Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС

Обмен с ГосИС WEB-интеграция Платформа 1С v8.3 Управляемые формы 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия государственного учреждения 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Обработка является альтернативой механизму, разработанному фирмой 1С и заполняющему реквизиты контрагента по ИНН или наименованию. Не требуется действующей подписки ИТС. Вызывается как внешняя дополнительная обработка, т.е. используется, непосредственно, из карточки контрагента. Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС (egrul.nalog.ru) для БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0, УТ 10.3, УТ 11.x, КА 1.1, КА 2.x, УПП 1.x, ERP 2.x, УНФ 1.5, УНФ 1.6, УНФ 3.0, ДО 2.1

2400 руб.

28.04.2016    88580    160    215    

318
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user618725_yurin 08.04.20 23:41 Сейчас в теме
Спасибо, мне статья была полезна.
user803412; +1 Ответить
2. nomad_irk 71 09.04.20 00:44 Сейчас в теме
Как по-мне, автор смешал в кучу мух и котлеты. Универсальный обмен XML - это способ сериализации данных, с применением КД 2/3.
Все остальное - это способы передачи уже сериализованных данных между учетными системами.

В том же DATAREON сериализацию можно выполнять внутренними средствами(java-script), либо прикрутить для этого тот же Универсальный Обмен XML и писать правила с использованием КД2/3.
doom2good; Lancelot-2M; Светлый ум; LeXXeR; chemezov; Витёк2010; SagittariusA; GreenDragon; awk; SergeRSA; dock; JohnyDeath; Aleskey_K; Andreeei; CodeNull; Comrade88; Doronichi; CyberCerber; Xershi; it_tungus; triviumfan; +21 Ответить
4. Nikola23 696 09.04.20 09:05 Сейчас в теме
(2) Афтар зрит в корень. Речь, конечно же об обработке Выгрузка загрузка данных XML. Поправил.
user803412; +1 Ответить
49. CodeNull 10.04.20 05:10 Сейчас в теме
(2) Присоединяюсь. В одну кучу смешаны способы доставки (http), форматы сериализации и готовые фреймворки для обмена (КД).
doom2good; user803412; Aleskey_K; zqzq; +4 Ответить
3. kuzyara 1900 09.04.20 08:07 Сейчас в теме
5. dsdred 3251 09.04.20 09:21 Сейчас в теме
Скорость Com и http\web сервисов в одном временном окне... Вы серьезно?

Объем данных - влияет на скорость выполнения обмена. Для оценки трафика http выполнялось сохранение передаваемых данных в файл


В заголовке Content-Length - указывает размер тела объекта в десятичном числе октетов (байтов)
CodeNull; +1 Ответить
6. Nikola23 696 09.04.20 09:52 Сейчас в теме
(5) Я серьезно. Это ж мой опыт.
Ваш, очевидно, другой.

А что конкретно вам не нравится?

Про "Content-Length" записал в блокнотик. Когда-нибудь пригодится.
7. nomad_irk 71 09.04.20 09:59 Сейчас в теме
(6)В случае DATAREON, вы явно погорячились насчет 1-5 сек в колонке "скорость". Такое возможно, в случае 2-х обменивающихся систем простейшими данными, типа справочник Валюты, как это показывается в презенташке.
В реальных условиях никто в здравом уме не станет городить DATAREON для двух учетных систем и обмена таким ничтожным объемом данных.
10. Nikola23 696 09.04.20 10:07 Сейчас в теме
(7) У меня есть опыт донастройки Датареон. Хорошо, что внедрял не я) Действительно, в здравом уме это не надо.

В реальных условиях настраивал и для 2х учетных систем. Поэтому ваше утверждение про "никто" - не верно.

Да, он за 1-5 сек он передавал данные, хотя иногда и встречались паузы. Но это обусловлено архитектурой решения.
8. dsdred 3251 09.04.20 10:00 Сейчас в теме
(6)
А что конкретно вам не нравится?

У http-сервиса 1-5 секунд... обычно до 1 секунды и то в первое подключение, а при повторном использовании сеанса...

А при больших объемах обмена http-сервисы вообще в разы быстрее Com'а...
9. Nikola23 696 09.04.20 10:07 Сейчас в теме
(8) Будьте внимательны, пожалуйста: речь об обмене одним элементом справочника Номенклатура.
В целом Вы правы, но в рамках примера - не уверен.

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

Обратили ли вы внимание, что Http сервис оказался в победителях? Причины ровно те, что вы указали в своем комменте)
11. nomad_irk 71 09.04.20 10:12 Сейчас в теме
(9)
Цель публикации - как раз в сравнении.

В таком случае смысл вашей публикации стремится к 0 с очень большой скоростью, т.к. сравнения, можно сказать, вообще не получилось из-за ничтожного объема.
ixijixi; cheburashka; Artem-B; CodeNull; Doronichi; +5 Ответить
12. Nikola23 696 09.04.20 10:12 Сейчас в теме
(11) Напишите свою. Критиковать - каждый умеет)
П,С, а какой объем для публикации считается приемлемым? Сколько символов?
13. nomad_irk 71 09.04.20 10:18 Сейчас в теме
(12)Поэтому я и не пишу :)
У меня есть пока данные по синхронизации между 1С: ЗУП2.5, 1С: ЗУП 3.1, 1С: УПП, 1С: ERP, 1С: УХ с помощью самостоятельно разработанного механизма синхронизации, с использованием WS и MSSQL таблички, в качестве резервного канала.

Максимум пока было, что 800к сформированных сообщений в 1С ЗУП 3.1 примерно за 2-3 часа рассосалось по 1С: УПП, 1С: ERP, 1С: УХ. и эти сообщения уж точно не по условному справочнику "номенклатура".
14. Nikola23 696 09.04.20 10:25 Сейчас в теме
(13) Печально, что у каждого свой инструмент для быстрых обменов (зато 100% решающий конкретную задачу)
Завтра на митапе презентую еще один, но универсальный под все задачи.
Приходите)
15. nomad_irk 71 09.04.20 10:28 Сейчас в теме
(14) У нас в планах универсализировать эти алгоритмы для всех наших систем(в том числе и не на базе 1С), выделить это все в отдельную конфигурацию и сделать БД - этакий вариант шины на базе 1С.
Про шину от 1С мы в курсе, скоро будем ее тестировать.
16. Nikola23 696 09.04.20 10:36 Сейчас в теме
(15) Могу дать потестить готовое решение.
Оно в открытом доступе, просто до завтра ссылку не публиковал.

В конечном счете - http сервис + JSON. И куча кода, что бы не заморачиваться и платформа не падала) Иногда - падает, если влоб писать код.
17. nomad_irk 71 09.04.20 10:39 Сейчас в теме
(16)Решения у нас есть, выбираем оптимальное для наших реалий.
JSON кстати, на значениях типа дата ведет себя странно в 1С, либо просто нужно настроить, поэтому обмениваемся XML.
19. Nikola23 696 09.04.20 10:46 Сейчас в теме
(17) Ада, дата в одну сторону получается, а в обратную - нет (на автомате).
Но XML - избыточен же?
На больших объемах данных в вашем случае это имело значение?
24. nomad_irk 71 09.04.20 10:57 Сейчас в теме
(19)Большие объемы было решено архивировать, результат в BASE64, массив таких сообщений - в XML.
Т.е. Сериализуем объект в XML типовой обработкой "Универсальный Обмен XML" с архивированием результата, полученный файл - в BASE64, набираем некий массив сообщений BASE64, сериализуем этот массив в XML и отправляем по WS. Если по WS отправить не удалось, то просто каждое сообщение BASE64 складываем в табличку MSSQL.

Получилось достаточно компактно.
22. Nikola23 696 09.04.20 10:55 Сейчас в теме
(17)
JSON кстати, на значениях типа дата ведет

Я при анализе данных json выделяю там даты и отдельно конвертирую.
Закодил в формате фреймворка, чтобы не тратить на это время на каждой следующей задаче.
23. dsdred 3251 09.04.20 10:55 Сейчас в теме
(16)Любопытно глянуть.
У меня тоже универсальное решение на http-сервисах и тоже хотел на митапе(Екатеринбург) рассказать.
38. nomad_irk 71 09.04.20 13:28 Сейчас в теме
(12)Объем в данном конкретном случае относится к данным, передаваемым между учетными системами с помощью обозначенных в публикации способов.
Передавать один элемент справочника номенклатуры - это курам на смех, т.к количество времени затраченное на передачу будет у всех способов примерно одинаковым.
Передавайте хотя бы 100к элементов поэлементно/порциями, чтобы была видна масштабируемость каждого из способов.
Fox-trot; +1 Ответить
18. itmind 308 09.04.20 10:42 Сейчас в теме
КД3 это просто один из способов формирования xml для обмена, аналог ручного формирования xdto пакета для передачи через HTTP API. Для КД3 в БСП есть HTTP сервис для обмена. Как вы замеряли скорость и получили такое же время как в КД2? Это же совсем разные технологии.
20. Nikola23 696 09.04.20 10:47 Сейчас в теме
(18) В случае с КД2/3 обмен выполнялся через файл.
На малых данных разница в пределах погрешности.
На больших массивах в имеющихся у меня базах КД3 работает быстрее.
21. Nikola23 696 09.04.20 10:49 Сейчас в теме
(18)
Как вы замеряли скорость и получили такое же время как в КД2

КД2 = бесконечно, Кд3 = бескончено.
Наверное, бесконечности одинаковы. Но, разница все-такие есть).
25. Darklight 32 09.04.20 10:59 Сейчас в теме
Хорошо было бы дать ссылки на описание каждой технологии шины данных, в идеале, на статьи с применением оных в среде 1С. Ну или хотя бы дать краткую расшифровку принципов действия в данной статье - не все же тут специалисты по обмену данными. Например, я не сразу понял, что КД2 и КД3 - это Конвертация Данных, соответственно 2-го и 3-го поколения (увидел примечание только кода уже написал это примечание вверху размещать) . Ну а COM, HTTP, SOAP - так это вообще только протоколы - без какой-либо инфрасттруктуры обмена сообщениями - таким же образом можно было написать XML и JSON - как средства обмена. Тем более - вообще не понятно - какую разницу вы закладываете между SOAP и HTTP - если SOAP и так задействуется поверх HTTP и просто задаёт абстрактный формат текстового обмена (автоматически применяемый в WEB-сервисах), а HTTP - это только низкоуровневый транспортный протокол - в котором вообще нет никакого API для организации обмена. Если хотели разделить WEB\HTTP сервисы - тогда так бы и писали - только большой разницы для обмена тут нет - разве что HTTP сервисы полегче в трафике и в прозрачной интеграции в WEB-страницы, а WEB-Сервисы более широки как способ интеграции между приложениями

А аргумент против "Неведомый зверь" у Kafka - так вообще убил своим невеждеством :-(
dock; Bassgood; Doronichi; CyberCerber; +4 Ответить
36. Nikola23 696 09.04.20 13:17 Сейчас в теме
(25) "невежеством", а не невежДеством. Второй слово обозначает совсем другое.

Неве́жество — недостаток знаний, необразованность, неразвитость, отсталость. Согласно словарю Ушакова — отсутствие познаний, некультурность, отсталость; в другом, разговорном значении — невоспитанность, невежливость.
Невежество — Википедия

Коллега, вы прежде,чем писать буквы, поработайте надо своим "вежеством".

По существу. Я использую терминологию, которой оперирует известное мне большинство, в т.ч. на ИС. Вероятно, вы к этому большинству не относитесь. Вот и будет повод познакомиться.

То, что эта терминология далека от идеальной - факт.
Тем не менее, обмен через COM, обмен через XML, обмен через http сервисы - распространенные выражения.
26. Xershi 1474 09.04.20 11:00 Сейчас в теме
Я думаю стоит заменить заголовок на краткий анализ.
Т.к. описания технологий скудное. Замер скорости работы не объективный и без анализа узких мест.
Нет это хорошо, что вы хоть что-то опубликовали, но плохо, что так коряво.
Для неофитов и то хлеб, но для тех кто с этим работает вызывает только улыбку!
Aligator69; Kolobash95; CodeNull; Bassgood; tormozit; Fox-trot; CyberCerber; Darklight; +8 1 Ответить
34. Nikola23 696 09.04.20 13:12 Сейчас в теме
27. XSlava 157 09.04.20 11:46 Сейчас в теме
Все изложенное очень субъективно. Каждый раз, принимать решение нужно исходя из поставленное задачи.
Nikola23; +1 Ответить
28. rpgshnik 3631 09.04.20 12:14 Сейчас в теме
TXT

NikeeNik; maksa2005; user803412; muskul; Bassgood; Nikola23; +6 Ответить
29. nbeliaev 828 09.04.20 12:26 Сейчас в теме
Заголовок публикации звучит интересно, но содержание очень слабое. Еще очень странные временные оценки на изучение. Это как C++ за 21 день...
user1616672; wowik; cheburashka; Kolobash95; zqzq; Bassgood; CyberCerber; +7 Ответить
32. Nikola23 696 09.04.20 13:11 Сейчас в теме
(29) Наверное, стоит как-то жирными буквами, что ли выделить текст "понимания" в фразе ниже.

Изучение - оценка минимального времени в часах с момента знакомства до появления "понимания" как решать задачу
33. Nikola23 696 09.04.20 13:12 Сейчас в теме
(32) Понимание - это не значит быть гуру или хотя бы мидлом)
о в целом отклик сообщества понятен - надо работать над полнотой материала.
30. Doronichi 09.04.20 12:43 Сейчас в теме
Мастер заголовка. Видишь заголовок, думаешь, что оооо, сейчас что-то интересное прочитаю.
У тут ни по качеству, ни по объему.
Постеснялись бы.
31. Nikola23 696 09.04.20 13:09 Сейчас в теме
(30) Я вижу, что сообщество любит размеры)
35. Xershi 1474 09.04.20 13:16 Сейчас в теме
(31) качество в первую очередь!
37. Nikola23 696 09.04.20 13:20 Сейчас в теме
(35) Боюсь, что комментов про размеры я насчитал больше)
Я тоже за качество. Но не любой ценой)
Я хотел выложить таблицу - выложил)
В то, что кому-то мало - могу только предложить дополнить.
39. Xershi 1474 09.04.20 13:31 Сейчас в теме
(37) суть в том что качество материала хромает. И видно уровень автора, прошлись по верхам. Поэтому и рекомендую, если будете развивать статью, ставьте ремарку, если нет то поменяйте заголовок, чтобы он отражал уровень статьи.
40. Doronichi 09.04.20 13:38 Сейчас в теме
(39) Согласен, с одной стороны
Но, с другой. Там дополнять странно. Нужно заново все переписать. Для начала вообще вникнуть в тему.
41. Nikola23 696 09.04.20 13:38 Сейчас в теме
(39) Коллега, бегло ознакомился с вашими работами.

Помогите мне стать лучше:
Перечислите, пожалуйста критерии качества: в килограммах (т.е. с цифрами), без оценок им сравнений теплого с красным.

При чем уту ваши статьи? на Ваших примерах покажите.
А чтобы не раздувать офтоп - переводите в личку, пожалуйста.

Хотя, не. Чем больше мы тут переписываемся, тем дольше статья остается на первой странице.
Тем кому достаточно таблицы и выводов - будет полезно)
42. Xershi 1474 09.04.20 13:44 Сейчас в теме
(41) критерий качества для неофитов полнота информации (они же не знаю, как оно на самом деле) и простота ее усваивания.
Для профессионалов точная информация со всеми подводными камнями и скорость применения у себя в проекте.

Для примера можете взять Универсальный монитор лицензий 1С.
Кратко, но все по делу. Да и чисто статьи я редко пишу.
Правда для неофитов материал тяжелый и даже минусы поставили)

Также последняя статья Эволюция расширения конфигурации, грубо говоря копипаст из обновлений, но материал структурирован и тоже хорошо зашел. Сам пользуюсь, как шпаргалкой. У клиентов же разные платформы стоят и нужно изворачиваться!
43. nomad_irk 71 09.04.20 13:45 Сейчас в теме
(41)
Тем кому достаточно таблицы и выводов - будет полезно)

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

Как пример выводов:
https://infostart.ru/public/1119024/

хоть помидорами покидайтесь что ли :)
44. awk 741 09.04.20 13:58 Сейчас в теме
Поставил минус т.к.:

Сравнивается теплое с мягким. Маппинг (КД2, КД3), транспорт и их смесь. А рекомендация с сервисами - вообще трэш, т.к. поощрение зоопарков.
wowik; zqzq; CodeNull; Bassgood; Xershi; +5 Ответить
45. Dragonim 139 09.04.20 16:01 Сейчас в теме
"Что это? Зачем это? Почему это?" вот такими вопросам заполнился мой мозг по итогу прочтения, а теперь конкретизирую:

Есть типовая УТ последней версии, есть типовая БП 3 последней версии. Они постоянно обновляются. Стоит задача их синхронизирует. Вы предлагаете мне построить http сервис для решении этой задачи?

Есть самописная база и из неё надо выгрузить единоразово всю номенклатуру в новую типовую базу. Может быть для этого стоит построить http сервис?

Есть сайт-магазин на общедоступной известной платформе. Платформа сайта позволяет из коробке обмениваться данными с типовой конфигурацией. Руководитель поставил задачу наладить обмен между сайтом и 1С. Может быть мне надо начать уговаривать разработчикам платформы сайта чтобы они добавили обмен через http сервис, а потом доработать 1С?

Есть две сильно изменённые конфигурации и ещё 101+ сервис вокруг. В конфигурациях много данных и они крутятся на мощном сервере. Нужно обеспечить обмен. Может быть вокруг этого построить http сервис? Я вас огорчу, во круг этого уже кто-то что-то построил в течении развития данной системы от маленькой до текущего состояния, а теперь с этим приходиться жить. Перестраивать данную систему на http сервис разработчики будут когда закончат все текущие срочные задачи, т.е. никогда.

Так ответьте же мне на вопросы:
1. Зачем вы в таблицу ввели показатели "Изучение", "Доработка", "Создание" если они взяты "не по себе, а из наблюдений за своими сотрудниками." (это цитата). Вы решили померить среднюю температуру по больнице наблюдая как окружающие мерят свою личную температуру градусником?
2. Что вы замеряли в графе "скорость" если у вас там стоит "бесконечно"? Вы вообще в курсе что означает понятие бесконечности?
3. Почему в столбце "Аргумент за" в у http сервиса стоит красноречивое "По совокупности показателей - лучшее решение". Может быть создавая таблицу вы были предвзяты?
ixijixi; wowik; rozer; Andreeei; Doronichi; +5 Ответить
46. Nikola23 696 09.04.20 16:17 Сейчас в теме
(45) Коллега, столько эмоций, мне кажется вы предвзяты. Хотя, может быть я ошибаюсь?

Не предлагаю переделывать, где вы это вычитали?. Работает - не трожь.

А вот если стартуете разработку нового механизма - предлагаю.

Обмен с Битриксом. Любимая тема для доработки у меня. Типовой механизм - тормозной, сложный, сайт можно положить при обмене.
Говорить про обмен "онлайн" не стоит)
На всех серьезных задачах - обмен с сайтом разрабатывался с нуля. Для 3х заказов в день - не обосновано, конечно.
Можем подискутировать, но это отдельная тема.

1. Ввел в таблицу колонки, потому что ее читают не только сотрудники в штате, но и руководители. А им это важно (опросил почти 100 человек за год).
2. "Бесконечно" - в сравнении с другими решениями - подсчет не имеет смысла.
3. Действительно. Люблю http сервисы.
47. acanta 09.04.20 16:42 Сейчас в теме
Спасибо, очень полезный обзор. В кд 2 мне не хватало возможностей выгрузки в произвольный формат. Кд 3 эту потребность с учетом модификации ed полностью удовлетворяет.
48. Nikola23 696 09.04.20 16:47 Сейчас в теме
(47) Заходи на митап завтра, тема получит развитие)
50. dock 44 12.04.20 00:40 Сейчас в теме
Не могу пройти мимо такого холивара!

Http сервисы. JSON без сохранения в файл.
WEB сервисы. XML без сохранения в файл.


Почему такая однозначность ?

В нашем зоопарке есть web-сервисы, которые обмениваются по XML, XDTO, json и о чудо, через ХранилищеЗначения ...
а есть HTTP-сервисы, которые точно также обмениваются через XML, XDTO, json...

Может всё-таки протокол доступа и и формат данных это разные вещи ? :)
Doronichi; +1 Ответить
51. Nikola23 696 12.04.20 21:16 Сейчас в теме
(50) Кончено. Опишите все многообразие с замерами?) Я дополню.
52. dock 44 12.04.20 23:22 Сейчас в теме
(51) А в чем смысл описания этого многообразия? Потратить кучу времени на замер милисекунд?
Доказать, что http-сервис быстрее чем web-сервис?
Так это ясно из архитектуры: http сам по себе проще. web - более универсален, генерирует больший трафик. Является развитием hhtp для упрощения жизни программиста, позволяет даже такие вольности, как ХранилищеЗначения.
XDTO, XML, JSON
Перечислил в порядке уменьшения объема информации для одних и тех же данных. Скорость передачи по одному и тому же протоколу напрямую зависит от объема...
Сложность работы с форматом - порядок тот же в сторону уменьшения.


Дикий винегрет протоколов, форматов и инструментов, слегка приправленный технологиями не я первый начал :)
Прежде чем браться за какой либо анализ, нужно изучить теоретическую базу. Что бы не давать ошибочных утверждений, типа "Http сервисы. JSON без сохранения в файл."
53. Nikola23 696 13.04.20 12:16 Сейчас в теме
(52)
Так это ясно из архитектуры

Я вижу, что вы не первый год в отрасли. Но почему тогда до сих пор не поняли, что то, что очевидно для вас - не очевидно для всех окружающих?

"Http сервисы. JSON без сохранения в файл"
Что ж нем ошибочного? По вашему формате JSON через HTTP сервисы нельзя отправить данные?
И да! сохранение в файл при конвертации в JSON или отправке тела запроса на производится (на ИС есть примеры, которые используют временный файл для этих операций).
Изучайте, коллега....
54. dock 44 13.04.20 14:13 Сейчас в теме
(53) Коллега! меньше эмоций, больше дела!
В комментариях мы обсуждаем опубликованный материал с целью улучшить контент!
Автор должен быть готов как к "хвалебным", так и к негативным отзывам. И относятся эти отзывы в первую очередь, не к самому автору, а к материалу статьи.

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

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


Осторожно! дальше много буковок!

1) я задал вопрос: зачем делать замеры, если они очевидны ?
web-сервис является развитием http с усложнением для большей универсальности, стандартизации и упрощения работы программиста в ущерб скорости за счет увеличения объема передаваемых. Да, немного "вольное" изложение теории web-сервисов. Если в теоретическом материале говорится о том, что этот протокол медленнее, то и результат замера будет очевиден: на выбранном вами объеме данных от пары миллисекунд до 0.

Но почему тогда до сих пор не поняли, что то, что очевидно для вас - не очевидно для всех окружающих?

а теперь я совсем запутался: что же это что-то, что очевидно для меня и не очевидно для всех окружающих ?

2)
"Http сервисы. JSON без сохранения в файл"
Что ж нем ошибочного? По вашему формате JSON через HTTP сервисы нельзя отправить данные?

Я как раз говорю о том, что посредством HTTP-сервиса можно передать не только JSON.
Точно так же, как посредством web-сервиса не только XML
При прочтении статьи складывается впечатление, что Http сервисы = JSON, WEB сервисы = XML
Подчеркивается это впечатление критерием выбора для строки "WEB сервисы"
"Надо веб-сервер и подучить XDTO. Зачем, если есть Http сервисы?"
у меня, например, возник вопрос: Зачем учить XDTO, если можно использовать JSON ?

3)
И да! сохранение в файл при конвертации в JSON или отправке тела запроса на производится (на ИС есть примеры, которые используют временный файл для этих операций).
Изучайте, коллега....

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

Основной вопрос в том, что статья является мешаниной инструментов, сервисов, форматов данных. Об этом указано далеко не в одном комментарии.
Простой пример:
В сообществе описанные решения, обычно, носят нарицательное значение. Но не все это понимают, судя по комментариям.
Выгрузка загрузка данных XML. XML с сохранением в файл.
КД2. XML с сохранением в файл.
КД3. XML с сохранением в файл.

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

Rabbit. JSON без сохранения в файл.
Datareon. XML без сохранения в файл.
Kafka. JSON без сохранения в файл.

"Неведомое зверье" не из "мира 1С". :)
замечание: Rabbit - имеется ввиду "RabbitMQ — программный брокер сообщений на основе стандарта AMQP — тиражируемое связующее программное обеспечение" ?

COM. Нативное кодирование без особых хитростей.

имеется ввиду Component Object Model — объектная модель компонентов, разработанная компанией Microsoft. ?
даже не знаю... инструмент, технология... но уж точно не решение :)
насчет "хитростей"...
советую почитать Взаимодействие между базами 1С через COM



Http сервисы. JSON без сохранения в файл.
WEB сервисы. XML без сохранения в файл.


Вот только тут соглашусь, что указаны решения.
При этом абсолютно без описания, критериев выбора:
Сервис такой-то, формат данных такой-то... изучил за 5-10 часов, обменивается за 1-5 секунд... web-сервис не понравился, потому что нужен XDTO...

З.Ы, Кстати именно о технологиях обмена данными вы совершенно ничего не сказали...
serge_focus; Artem-B; tormozit; Nikola23; +4 Ответить
55. Nikola23 696 13.04.20 15:38 Сейчас в теме
(54) Поставлю вам плюс, не дочитав до конца.
Ваше мнение хотя бы обоснованное. Ничего, что расходится с моим)

Пожалуй, заголовок статьи действительно стоит заменить.
56. Nikola23 696 15.04.20 09:18 Сейчас в теме
(54)
Как КД2, так и КД3 - незаменимые инструменты для создания решения: "двухсторонний обмен между конфигурациями."

Вот прям вижу, что стоит мне это написать как проклюнутся специалисты с комментариями типа: "а для одностороннего обмена не подходит что ли? Читай матчасть"
КД - это не только конфигурация но и сами правила. которые получены с использованием этой конфигурации.
КД - устоявшийся термин в сообществе и не требует детального разжовывания. ИМХО.
58. dock 44 15.04.20 14:14 Сейчас в теме
(56)
Зависит от того, как позиционируется материал в целом и каков контекст данного предложения в частности.
а) если убрать "незаменимые", то получается однозначное утверждение, с которым можно поспорить.
б) если перед этим написать "КД - инструмент для создания правил ...", то "КД - незаменимые инструменты для..." уже "звучит" совсем по другому...

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

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

З.Ы. Эх... вот они последствия тесного общения с нормоконтролем...
"Но тут же всего-то запятая!" - "Тебе что, сложно исправить? Иди исправляй!"
59. Nikola23 696 15.04.20 14:38 Сейчас в теме
(58) Всем не угодишь. Хорошо, что не все общаются с нормоконтролем.
Учту полученный опыт в следующей статье.
57. dock 44 15.04.20 14:03 Сейчас в теме
просто пустой комментарий...
60. acanta 15.04.20 14:40 Сейчас в теме
Было бы интересно узнать как использовать схемы xsd для более компактного представления данных xml и как их получить в КД.
61. Nikola23 696 15.04.20 23:58 Сейчас в теме
(60) Наверное, это интересно. Но я XML не люблю (только потому, что JSON занимает меньше места = физический размер компактнее). Потому не смогу помочь.
А для какой задачи XML был бы оптимальным решением?
62. d4rkmesa 20.04.20 08:40 Сейчас в теме
(61) Пардон, что влезаю в диалог, возможность вызвать метод ОбъектXDTO.Проверить() - отличная штука. Т.е. можно сразу сделать xml, соответствующий формальным требованиям, в основном, по крайней мере(т.к. не всегда то, что в xsd-схеме на 100% соответствует требованиям в документации).
69. Nikola23 696 08.02.22 23:56 Сейчас в теме
(62) Согласен - отличная штука.
Просто работает медленнее. И кодить больше.

Конечно же, если у вас в день 10-100-1000 сообщений обмена - скорость не играет существенной роли. Наверное.
63. Aligator69 30.06.21 14:05 Сейчас в теме
Было бы здорово увидеть аналитику по скорости обмена на базе HTTP сервисов и COM соединений.
Так же круто было бы добавить в статью более обширное описание логики работы с этими двумя технологии (на примере переноса номенклатуры между 2мя базами) - только в примере использовать какую то более менее реальную базу с 60 реквизитами и что бы половина из которых были Ссылками на другие справочники (единицы измерения, производитель, цвет итд итп)

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

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

Но простота реализации сразу отходит на второй план, когда у тебя 5 бухгалтерских и 5 управленческих баз, где каждое проведение документа открывает COM и дублирует проведенный в документ в половине других баз (это просто карусель страданий на самом деле).

ПОЭТОМУ, я думаю что архитектура по которой работает обмен - является самой весомой составляющей этой задачи.

Если мы говорим про обмен документами, то тут явно нужно создавать РегистрСведений в который будут записываться все проведенные документы, а уже регламент который будет выполнять обмен (тут мне кажется COM или HTTP сервис будут иметь одинаковую скорость)
68. Nikola23 696 08.02.22 23:53 Сейчас в теме
(63) COM - миллион раз проверено - медленная штука. Чуть меньшее количество раз оно описано в статьях.
Надо ли еще раз описывать?)

Как же без очередей? А вдруг обрыв связи? Нормальный брокер сообщений, пусть и реализованный на платформе 1с без очередей не выживет.

Вижу в конце своего комментария вы тоже приходите к выводу, что где-то очередь надо хранить. В РегистреСведений - почему бы и нет?)
70. Aligator69 14.02.22 13:52 Сейчас в теме
(68) это точно будет не оптимальное решение, работать будет медленно. Все зависит от задачи, думаю что если 1С занят, то очередь запросов лучше похранить на клиенте
71. Nikola23 696 16.02.22 09:36 Сейчас в теме
(70) очередь на клиенте?
При любом раскладе - очередь - это какая-то таблица на сервере.
Можно, конечно в оперативке очередь держать или в какой-то файл на клиенте засунуть, но это какой-то нестандартный подход.

На счет оптимальности решения вот такой комментарий.
Все варианты шин с коннекторами для 1с (например, датареон, редмул) хранят свои очереди.
Хранят на сервере, в регистрах сведений.
И работают)

И в моем случае - работает тоже)

Нагрузка 800 000 чеков ккм в сутки + всякие справочники - вполне посильная задача.

Потому вопрос, на чем основано ваше утверждение, что работать будет медленно?
64. starik-2005 3033 19.10.21 11:27 Сейчас в теме
Надо веб-сервер и подучить XDTO. Зачем, если есть Http сервисы?
Ну как бы в 99,9% случаев можно передать хранилище значений (если из одной 1С в другую), ну и не жрет лицуху (которую жрет HTTP, а заставить отдать лицуху после отработки я, например, так и не понял, как - может расскажете).

Если интеграция с чем-то неведомым, то WS вполне может "принять на грудь" и JSON, который можно засунуть хоть в base64, хоть есчё во что (ну чтобы XDTO не "учить").
67. Nikola23 696 08.02.22 23:51 Сейчас в теме
(64)
Не понял, вы присоединяетесь к автору или занимаете противную сторону?)

В JSON через http сервисы хранилище значения передается не хуже, чем через XDTO.
Надо только замерить объем передаваемых данных. Нет у меня статистики где будет больше.
Чувствую, что JSON проиграет. Но насколько?
65. axelerleo 338 07.02.22 13:08 Сейчас в теме
Спорное утверждение, что "использование HTTP сервисов и данных в формате JSON - оптимальный выбор"
Как минимум:
в КД можно прописать сложные алгоритмы пред/пост/во-время- обработки данных, распихивание одного объекта источника в несколько объектов приемников, и плюс там куча всякой логики для интеграции 1С-1С. Да, комбайн, и требует обучения, но для сложных интеграций 1С-1С инструменты пока еще незаменимые.
Брокеры сообщений - кафки, кролики и прочие. Им точно также можно скармливать json. Преимущество - в гарантированной доставке сообщения. Если бы это была бесперспективная технология, 1С не стало бы в платформу добавлять Сервисы интеграции
SOAP сервисы. Многословны, тяжелы в поддержке (на любой чих надо менять схему XDTO, типы данных и т.д.) Но зато полностью сами себя описывают - и это таки преимущество. Можно получить схему wsdl, и будешь знать какие сервисы есть, какие параметры принимают, что возвращают.
HTTP сервисы - люблю их нежно! быстро в разработке, быстро в обмене. Но вот с описанием API и документацией "наружу" беда. Т.к. ее попросту нет. Зная адрес расположения веб-сервисов, внешняя система никак не может знать, какие параметры она может передать, какие вообще сервисы ей доступны для вызова, и что эти сервисы могут возвращать. Поэтому OpenApi, swagger, вот это вот все.

Так что для разных целей таки разные инструменты будут оптимальными.

З.Ы. - а почему, кстати, нет упоминаний об ODATA? там вообще CRUD можно организовать :)
66. Nikola23 696 08.02.22 23:48 Сейчас в теме
(65) неужели сложный алгоритм можно прописать только в КД?)

Гарантию доставки обеспечивает алгоритм. В брокерах он встроенный, учитывает всякие нюансы...
В 1с - надо свой аналог писать каждый раз и самому учитывать нюансы.
Но, брокер - это такая штука, которая может сломаться. Как и 1с.
И все же обмен 1с<->ЧтоТоТам или 1с<->1с - это 2 программы. А через брокер - 3 программы. И это надо поддерживать, и настраивать, и сломаться может уже в трех местах)
Ни в коем случае не отрицаю преимущества брокеров сообщений. И все же они не панацея)

Использовать тяжелые SOAP Только ради самоописания? Потому что было лень документацию сделать?
Поработайте, пожалуйста, с обменами где ресурсов мало, а сообщений обмена - много)

ODATA - а кто ж ее знает? Не нашел там ничего похожего на правила обмена.

HTTP сервисы - присоединяюсь к вашей любви.
72. Lancelot-2M 115 15.06.22 00:29 Сейчас в теме
Не вижу преимуществ http перед web(soap) при обмене 1с - 1с. Http тратит лицензии, а Web нет. Для вэб код компактнее, и работа концептуально проще - что может быть проще вызова метода с параметрами? А что в метод передавать уже сам решайте. Для мелких обменов чаще собираю нужные структуры данных "руками" и в json их, а json во входящий параметр.
А при интеграция с другими системами столкнулся, что у их программеров траблы с соап, а хттп делают быстро.
73. Nikola23 696 15.06.22 12:14 Сейчас в теме
(72) "А при интеграция с другими системами столкнулся, что у их программеров траблы с соап, а хттп делают быстро."
Не это ли преимущество чттп?)
Я исхожу из того же: хттп проще.

У меня лицензии хттп соединение не съедает. Не путать с веб-клиентом.
74. Lancelot-2M 115 16.06.22 17:06 Сейчас в теме
(73)
Не это ли преимущество чттп?)


Крайне условное преимущество... проявляется в связи с недостатками подготовки коллег из не 1С...
На php мне тут на днях моментом подключение к соап сваяли, например.
На делфи ребята попадались менее подготовленные, под андроид тоже,
но у меня около 80 процентов 1С-1С, а там проблем нет.
75. lemilk 2 24.11.23 16:47 Сейчас в теме
А Шину данных можно включить в это сравнение? Вроде как для обмена данными предназначена...
76. Nikola23 696 24.11.23 16:57 Сейчас в теме
(75) rabbit, datareon, kafka - это все про шину же
77. lemilk 2 24.11.23 17:03 Сейчас в теме
(76) я вот про эту шину https://v8.1c.ru/static/1c-shina/?
Или это способ интеграции различных технологий?
78. Nikola23 696 24.11.23 17:09 Сейчас в теме
(77) Пардон, 1с:Шина я не пользовался. Если у вас есть статистика - пришлите - я дополню таблицу
79. lemilk 2 24.11.23 17:17 Сейчас в теме
(78) Не пользовался потому и интересно. 1С недавно выпустила этот продукт, видимо должны были учесть преимущества и недостатки всего что было раньше. Вот и интересно что получилось и насколько трудоемко это использовать.
Оставьте свое сообщение