Почему использование HTTP сервисов и данных в формате JSON - оптимальный выбор, вместо всех остальных вариантов при решении задачи обменов данными
Многие разработчики, решая задачи обмена данными, используют те технологии, с которыми уже знакомы.
Кто-то лепит обмены через 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 шагов, достаточные, чтобы написать свой быстрый обмен:
2. Создать http-сервис
3. Опубликовать базу 1с
4. Выучить методы, отвечающие за конвертацию в JSON и обратно.
5. Выучить методы, отвечающие за отправку данных по протоколу HTTP.
Достаточно подробный пример реализации обмена можно найти в статьях от 18го года (начало тут).
Через 3 часа чтения и нажимания кнопок - ты уже молодой специалист :)
Но даже в такой простой штуке можно найти подводные камни, то JSON не конвертируется, рушит платформу, то данные не доставляются, а то и задача вырастает до 3000 строк кода. Для решения таких сложностей существуют библиотеки и фреймворки.
Но об этом - в следующей серии.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
WEB-интеграция Рабочее место Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Пользователь 1С:Предприятие 8 1С:Бухгалтерия 2.0 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 10 1С:Управление торговлей 11 1С:Розница 2 1С:Розница 3.0 Оптовая торговля, дистрибуция, логистика Россия Управленческий учет Платные (руб)
Программный продукт "Управление доставками в 1С" позволяет обмениваться с личным кабинетом Boxberry, СДЭК, Энергия, Почта России, DPD, ПЭК, Grastin, Деловые Линии, КСЕ, Dalli, ЯндексДоставка. Упрощает создание заявок и резервирование заказов прямо в интерфейсе 1С
24400 руб.
10.03.2016 76080 321 100
WEB-интеграция Разработчик Аналитик 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Оптовая торговля, дистрибуция, логистика ИТ-компания Платные (руб)
Модуль "Экспортер" — это расширение для 1С, предназначенное для автоматизации процессов выгрузки данных. Оно позволяет эффективно извлекать, преобразовывать и передавать данные из систем 1С в интеграционную платформу Spot2D. Подсистема упрощает настройку, снижает количество ручных операций и обеспечивает удобный контроль данных.
17568 руб.
20.12.2024 7750 35 4
Сайты и интернет-магазины WEB-интеграция Системный администратор Разработчик Пользователь 1С:Предприятие 8 1C:Бухгалтерия 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)
Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM / LOGICSTARS. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM / LOGICSTAR разных брендов в одной информационной базе в ручном и автоматическом режиме.
42700 руб.
03.08.2020 25816 42 26
WEB-интеграция Системный администратор Разработчик Пользователь 1С:Предприятие 8 1C:Бухгалтерия 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)
Интеграционный модуль обмена по API между конфигурацией 1С:Альфа-Авто 6 и порталом LogicStar. Позволяет работать с несколькими обменами LogicStars разных брендов (CHERY, OMODA, JAECOO, EXEED, TENET) в одной информационной базе в ручном и автоматическом режиме. Поддерживается выгрузка заказ-нарядов, реализаций товаров и товарных остатков.
20740 руб.
13.05.2025 3075 6 0
WEB-интеграция Оптовая торговля Розничная торговля Разработчик 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)
Модуль интеграции 1С с OpenCart 2.x, 3x позволяет обмениваться данными между OpenCart (самая популярная бесплатная cms для интернет-магазинов) и 1С:Предприятие 8.
6914 руб.
17.11.2015 135239 477 143
WEB-интеграция Разработчик Пользователь 1С:Предприятие 8 1C:Бухгалтерия Управленческий учет Платные (руб)
Хорошая основа вашего решения импорта данных статистики Яндекс.Метрики в информационную базу 1С. Получение счетчиков, запрос статистики, получение данных - все в одной обработке.
5094 руб.
21.06.2022 11405 12 0
WEB-интеграция Загрузка и выгрузка в Excel Разработчик Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Россия Платные (руб)
Расширение освободит вас от необходимости вручную обновлять информацию о товарах в группах ВКонтакте. Достаточно задать правила один раз, и система автоматически формирует файлы yml для дальнейшей загрузки в группы в ВК. Вы сможете легко выбирать, какие товары публиковать, создавая гибкие критерии отбора. Например, можно добавить важные для покупателей параметры: цвет, размер или другие характеристики.
12200 руб.
29.08.2025 3750 7 8
WEB-интеграция Аналитик Бухгалтер Пользователь 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Бухгалтерия государственного учреждения Россия Платные (руб)
Доступ в виде подписки к сервисам 1СПАРК Риски и 1С:Контрагент в «старых», но широко используемых конфигурациях.
6100 руб.
30.01.2019 28905 104 6
Все остальное - это способы передачи уже сериализованных данных между учетными системами.
В том же DATAREON сериализацию можно выполнять внутренними средствами(java-script), либо прикрутить для этого тот же Универсальный Обмен XML и писать правила с использованием КД2/3.
В заголовке Content-Length - указывает размер тела объекта в десятичном числе октетов (байтов)
В реальных условиях никто в здравом уме не станет городить DATAREON для двух учетных систем и обмена таким ничтожным объемом данных.
В реальных условиях настраивал и для 2х учетных систем. Поэтому ваше утверждение про "никто" - не верно.
Да, он за 1-5 сек он передавал данные, хотя иногда и встречались паузы. Но это обусловлено архитектурой решения.
У http-сервиса 1-5 секунд... обычно до 1 секунды и то в первое подключение, а при повторном использовании сеанса...
А при больших объемах обмена http-сервисы вообще в разы быстрее Com'а...
В целом Вы правы, но в рамках примера - не уверен.
Вы сядьте с секундомером и выполните обмен.
Я готов корректировать статистику, при наличии обоснованных и подтвержденных конкретикой замечаний. Цель публикации - как раз в сравнении.
Обратили ли вы внимание, что Http сервис оказался в победителях? Причины ровно те, что вы указали в своем комменте)
В таком случае смысл вашей публикации стремится к 0 с очень большой скоростью, т.к. сравнения, можно сказать, вообще не получилось из-за ничтожного объема.
У меня есть пока данные по синхронизации между 1С: ЗУП2.5, 1С: ЗУП 3.1, 1С: УПП, 1С: ERP, 1С: УХ с помощью самостоятельно разработанного механизма синхронизации, с использованием WS и MSSQL таблички, в качестве резервного канала.
Максимум пока было, что 800к сформированных сообщений в 1С ЗУП 3.1 примерно за 2-3 часа рассосалось по 1С: УПП, 1С: ERP, 1С: УХ. и эти сообщения уж точно не по условному справочнику "номенклатура".
Про шину от 1С мы в курсе, скоро будем ее тестировать.
Оно в открытом доступе, просто до завтра ссылку не публиковал.
В конечном счете - http сервис + JSON. И куча кода, что бы не заморачиваться и платформа не падала) Иногда - падает, если влоб писать код.
Т.е. Сериализуем объект в XML типовой обработкой "Универсальный Обмен XML" с архивированием результата, полученный файл - в BASE64, набираем некий массив сообщений BASE64, сериализуем этот массив в XML и отправляем по WS. Если по WS отправить не удалось, то просто каждое сообщение BASE64 складываем в табличку MSSQL.
Получилось достаточно компактно.
Передавать один элемент справочника номенклатуры - это курам на смех, т.к количество времени затраченное на передачу будет у всех способов примерно одинаковым.
Передавайте хотя бы 100к элементов поэлементно/порциями, чтобы была видна масштабируемость каждого из способов.
А аргумент против "Неведомый зверь" у Kafka - так вообще убил своим невеждеством :-(
Неве́жество — недостаток знаний, необразованность, неразвитость, отсталость. Согласно словарю Ушакова — отсутствие познаний, некультурность, отсталость; в другом, разговорном значении — невоспитанность, невежливость.
Невежество — Википедия
Коллега, вы прежде,чем писать буквы, поработайте надо своим "вежеством".
По существу. Я использую терминологию, которой оперирует известное мне большинство, в т.ч. на ИС. Вероятно, вы к этому большинству не относитесь. Вот и будет повод познакомиться.
То, что эта терминология далека от идеальной - факт.
Тем не менее, обмен через COM, обмен через XML, обмен через http сервисы - распространенные выражения.
Т.к. описания технологий скудное. Замер скорости работы не объективный и без анализа узких мест.
Нет это хорошо, что вы хоть что-то опубликовали, но плохо, что так коряво.
Для неофитов и то хлеб, но для тех кто с этим работает вызывает только улыбку!
Помогите мне стать лучше:
Перечислите, пожалуйста критерии качества: в килограммах (т.е. с цифрами), без оценок им сравнений теплого с красным.
При чем уту ваши статьи? на Ваших примерах покажите.
А чтобы не раздувать офтоп - переводите в личку, пожалуйста.
Хотя, не. Чем больше мы тут переписываемся, тем дольше статья остается на первой странице.
Тем кому достаточно таблицы и выводов - будет полезно)
Для профессионалов точная информация со всеми подводными камнями и скорость применения у себя в проекте.
Для примера можете взять .
Кратко, но все по делу. Да и чисто статьи я редко пишу.
Правда для неофитов материал тяжелый и даже минусы поставили)
Также последняя статья , грубо говоря копипаст из обновлений, но материал структурирован и тоже хорошо зашел. Сам пользуюсь, как шпаргалкой. У клиентов же разные платформы стоят и нужно изворачиваться!
Повторюсь: т.к. для сравнения(получения цифр, выдаваемых измерительными приборами) обозначенных способов обмена использовался 1(один) элемент справочника Номенклатура, то все выводы - ничтожны.
Как пример выводов:
хоть помидорами покидайтесь что ли :)
Есть типовая УТ последней версии, есть типовая БП 3 последней версии. Они постоянно обновляются. Стоит задача их синхронизирует. Вы предлагаете мне построить http сервис для решении этой задачи?
Есть самописная база и из неё надо выгрузить единоразово всю номенклатуру в новую типовую базу. Может быть для этого стоит построить http сервис?
Есть сайт-магазин на общедоступной известной платформе. Платформа сайта позволяет из коробке обмениваться данными с типовой конфигурацией. Руководитель поставил задачу наладить обмен между сайтом и 1С. Может быть мне надо начать уговаривать разработчикам платформы сайта чтобы они добавили обмен через http сервис, а потом доработать 1С?
Есть две сильно изменённые конфигурации и ещё 101+ сервис вокруг. В конфигурациях много данных и они крутятся на мощном сервере. Нужно обеспечить обмен. Может быть вокруг этого построить http сервис? Я вас огорчу, во круг этого уже кто-то что-то построил в течении развития данной системы от маленькой до текущего состояния, а теперь с этим приходиться жить. Перестраивать данную систему на http сервис разработчики будут когда закончат все текущие срочные задачи, т.е. никогда.
Так ответьте же мне на вопросы:
1. Зачем вы в таблицу ввели показатели "Изучение", "Доработка", "Создание" если они взяты "не по себе, а из наблюдений за своими сотрудниками." (это цитата). Вы решили померить среднюю температуру по больнице наблюдая как окружающие мерят свою личную температуру градусником?
2. Что вы замеряли в графе "скорость" если у вас там стоит "бесконечно"? Вы вообще в курсе что означает понятие бесконечности?
3. Почему в столбце "Аргумент за" в у http сервиса стоит красноречивое "По совокупности показателей - лучшее решение". Может быть создавая таблицу вы были предвзяты?
Не предлагаю переделывать, где вы это вычитали?. Работает - не трожь.
А вот если стартуете разработку нового механизма - предлагаю.
Обмен с Битриксом. Любимая тема для доработки у меня. Типовой механизм - тормозной, сложный, сайт можно положить при обмене.
Говорить про обмен "онлайн" не стоит)
На всех серьезных задачах - обмен с сайтом разрабатывался с нуля. Для 3х заказов в день - не обосновано, конечно.
Можем подискутировать, но это отдельная тема.
1. Ввел в таблицу колонки, потому что ее читают не только сотрудники в штате, но и руководители. А им это важно (опросил почти 100 человек за год).
2. "Бесконечно" - в сравнении с другими решениями - подсчет не имеет смысла.
3. Действительно. Люблю http сервисы.
WEB сервисы. XML без сохранения в файл.
Почему такая однозначность ?
В нашем зоопарке есть web-сервисы, которые обмениваются по XML, XDTO, json и о чудо, через ХранилищеЗначения ...
а есть HTTP-сервисы, которые точно также обмениваются через XML, XDTO, json...
Может всё-таки протокол доступа и и формат данных это разные вещи ? :)
Доказать, что http-сервис быстрее чем web-сервис?
Так это ясно из архитектуры: http сам по себе проще. web - более универсален, генерирует больший трафик. Является развитием hhtp для упрощения жизни программиста, позволяет даже такие вольности, как ХранилищеЗначения.
XDTO, XML, JSON
Перечислил в порядке уменьшения объема информации для одних и тех же данных. Скорость передачи по одному и тому же протоколу напрямую зависит от объема...
Сложность работы с форматом - порядок тот же в сторону уменьшения.
Дикий винегрет протоколов, форматов и инструментов, слегка приправленный технологиями не я первый начал :)
Прежде чем браться за какой либо анализ, нужно изучить теоретическую базу. Что бы не давать ошибочных утверждений, типа "Http сервисы. JSON без сохранения в файл."
Я вижу, что вы не первый год в отрасли. Но почему тогда до сих пор не поняли, что то, что очевидно для вас - не очевидно для всех окружающих?
"Http сервисы. JSON без сохранения в файл"
Что ж нем ошибочного? По вашему формате JSON через HTTP сервисы нельзя отправить данные?
И да! сохранение в файл при конвертации в JSON или отправке тела запроса на производится (на ИС есть примеры, которые используют временный файл для этих операций).
Изучайте, коллега....
В комментариях мы обсуждаем опубликованный материал с целью улучшить контент!
Автор должен быть готов как к "хвалебным", так и к негативным отзывам. И относятся эти отзывы в первую очередь, не к самому автору, а к материалу статьи.
У читателя имеются определённые ожидания, после прочтения заголовка:
- если в заголовке указано "анализ", то ожидаешь увидеть именно анализ ;
- если в заголовке анализ инструментов и технологий обмена, то как минимум ожидается четкое разделение: что есть инструмент и что есть технология, а мешанина решений из инструментов, протоколов и форматов без какого-либо указания что есть что просто ставит в ступор.
Поверьте, называлась бы статья: "Мой опыт по реализации обменов данных", были бы совершенно другие комментарии...
Осторожно! дальше много буковок!
1) я задал вопрос: зачем делать замеры, если они очевидны ?
web-сервис является развитием http с усложнением для большей универсальности, стандартизации и упрощения работы программиста в ущерб скорости за счет увеличения объема передаваемых. Да, немного "вольное" изложение теории web-сервисов. Если в теоретическом материале говорится о том, что этот протокол медленнее, то и результат замера будет очевиден: на выбранном вами объеме данных от пары миллисекунд до 0.
а теперь я совсем запутался: что же это что-то, что очевидно для меня и не очевидно для всех окружающих ?
2)
Что ж нем ошибочного? По вашему формате JSON через HTTP сервисы нельзя отправить данные?
Я как раз говорю о том, что посредством HTTP-сервиса можно передать не только JSON.
Точно так же, как посредством web-сервиса не только XML
При прочтении статьи складывается впечатление, что Http сервисы = JSON, WEB сервисы = XML
Подчеркивается это впечатление критерием выбора для строки "WEB сервисы"
"Надо веб-сервер и подучить XDTO. Зачем, если есть Http сервисы?"
у меня, например, возник вопрос: Зачем учить XDTO, если можно использовать JSON ?
3)
Изучайте, коллега....
Совсем не понял, к чему это замечание?
Можно использовать временный файл, можно использовать поток (без сохранения в файл) - совершенно с этим не спорю. Даже никаких замечаний не делал.
Вы использовали поток - это Ваш выбор.
Основной вопрос в том, что статья является мешаниной инструментов, сервисов, форматов данных. Об этом указано далеко не в одном комментарии.
Простой пример:
Выгрузка загрузка данных XML. XML с сохранением в файл.
КД2. XML с сохранением в файл.
КД3. XML с сохранением в файл.
"Выгрузка загрузка данных XML". Догадываемся о том, что имеется ввиду внешняя обработка (имеется как для управляемых, так и для обычных форм). Это прекрасный инструмент для своего круга задач. Кстати, создана с использованием конфигурации 1С КД2 и входит в поставку с этой конфигурацией.
"КД2" - Конфигурация "Конвертация данных". Инструмент для создания правил обмена между конфигурациями на основе БСП2 (библиотека стандартных подсистем версии 2.Х)
"КД3" - Конфигурация "Конвертация данных". Инструмент для создания правил обмена между конфигурациями на основе БСП3 (библиотека стандартных подсистем версии 3.Х)
С помощью этих конфигураций можно также сформировать внешние обработки для реализации решения: "ручной обмен, без внесения изменений в конфигурацию"
Как КД2, так и КД3 - незаменимые инструменты для создания решения: "двухсторонний обмен между конфигурациями."
Datareon. XML без сохранения в файл.
Kafka. JSON без сохранения в файл.
"Неведомое зверье" не из "мира 1С". :)
замечание: Rabbit - имеется ввиду "RabbitMQ — программный брокер сообщений на основе стандарта AMQP — тиражируемое связующее программное обеспечение" ?
имеется ввиду Component Object Model — объектная модель компонентов, разработанная компанией Microsoft. ?
даже не знаю... инструмент, технология... но уж точно не решение :)
насчет "хитростей"...
советую почитать
Http сервисы. JSON без сохранения в файл.
WEB сервисы. XML без сохранения в файл.
Вот только тут соглашусь, что указаны решения.
При этом абсолютно без описания, критериев выбора:
Сервис такой-то, формат данных такой-то... изучил за 5-10 часов, обменивается за 1-5 секунд... web-сервис не понравился, потому что нужен XDTO...
З.Ы, Кстати именно о технологиях обмена данными вы совершенно ничего не сказали...
Вот прям вижу, что стоит мне это написать как проклюнутся специалисты с комментариями типа: "а для одностороннего обмена не подходит что ли? Читай матчасть"
КД - это не только конфигурация но и сами правила. которые получены с использованием этой конфигурации.
КД - устоявшийся термин в сообществе и не требует детального разжовывания. ИМХО.
Зависит от того, как позиционируется материал в целом и каков контекст данного предложения в частности.
а) если убрать "незаменимые", то получается однозначное утверждение, с которым можно поспорить.
б) если перед этим написать "КД - инструмент для создания правил ...", то "КД - незаменимые инструменты для..." уже "звучит" совсем по другому...
Опять таки, использование устоявшихся сокращений допускается для материала, рассчитанного на узкий круг подготовленных читателей. В статье может посчитатся "плохим тоном" и вызвать придирки. В комментарии к этой статье воспринимается вполне нормальное - ибо уже есть требуемый контекст.
Если же это аналитическая статья для более широкого круга - использование сокращений без их расшифровки просто недопустимо. Не просто так же вводятся стандарты оформления...
Используется два подхода (как по отдельности, так и вместе):
- при первом упоминании приводится полное наименование, с указанием сокращения;
- вводится отдельный радел, в котором перечисляются все использованные сокращения.
З.Ы. Эх... вот они последствия тесного общения с нормоконтролем...
"Но тут же всего-то запятая!" - "Тебе что, сложно исправить? Иди исправляй!"
Так же круто было бы добавить в статью более обширное описание логики работы с этими двумя технологии (на примере переноса номенклатуры между 2мя базами) - только в примере использовать какую то более менее реальную базу с 60 реквизитами и что бы половина из которых были Ссылками на другие справочники (единицы измерения, производитель, цвет итд итп)
Просто принятие решение по поводу выбора того или иного варианта зачастую вызывает затруднения, поскольку явно ощущается невообразимое количество подводных камней.
Если анализировать по простоте реализации то (как по мне) такую задачу проще делать на COM из-за отсутствия необходимости изобретать велосипед в виде механизма очереди, так же формирование пакетов можно избежать используя обычные объекты запросов, а про создание сущностей программным путем я вообще молчу (кода в случае использования HTTP-сервисов явно будет больше)
Но простота реализации сразу отходит на второй план, когда у тебя 5 бухгалтерских и 5 управленческих баз, где каждое проведение документа открывает COM и дублирует проведенный в документ в половине других баз (это просто карусель страданий на самом деле).
ПОЭТОМУ, я думаю что архитектура по которой работает обмен - является самой весомой составляющей этой задачи.
Если мы говорим про обмен документами, то тут явно нужно создавать РегистрСведений в который будут записываться все проведенные документы, а уже регламент который будет выполнять обмен (тут мне кажется COM или HTTP сервис будут иметь одинаковую скорость)
Надо ли еще раз описывать?)
Как же без очередей? А вдруг обрыв связи? Нормальный брокер сообщений, пусть и реализованный на платформе 1с без очередей не выживет.
Вижу в конце своего комментария вы тоже приходите к выводу, что где-то очередь надо хранить. В РегистреСведений - почему бы и нет?)
При любом раскладе - очередь - это какая-то таблица на сервере.
Можно, конечно в оперативке очередь держать или в какой-то файл на клиенте засунуть, но это какой-то нестандартный подход.
На счет оптимальности решения вот такой комментарий.
Все варианты шин с коннекторами для 1с (например, датареон, редмул) хранят свои очереди.
Хранят на сервере, в регистрах сведений.
И работают)
И в моем случае - работает тоже)
Нагрузка 800 000 чеков ккм в сутки + всякие справочники - вполне посильная задача.
Потому вопрос, на чем основано ваше утверждение, что работать будет медленно?
Если интеграция с чем-то неведомым, то WS вполне может "принять на грудь" и JSON, который можно засунуть хоть в base64, хоть есчё во что (ну чтобы XDTO не "учить").
Не понял, вы присоединяетесь к автору или занимаете противную сторону?)
В JSON через http сервисы хранилище значения передается не хуже, чем через XDTO.
Надо только замерить объем передаваемых данных. Нет у меня статистики где будет больше.
Чувствую, что JSON проиграет. Но насколько?
Как минимум:
в КД можно прописать сложные алгоритмы пред/пост/во-время- обработки данных, распихивание одного объекта источника в несколько объектов приемников, и плюс там куча всякой логики для интеграции 1С-1С. Да, комбайн, и требует обучения, но для сложных интеграций 1С-1С инструменты пока еще незаменимые.
Брокеры сообщений - кафки, кролики и прочие. Им точно также можно скармливать json. Преимущество - в гарантированной доставке сообщения. Если бы это была бесперспективная технология, 1С не стало бы в платформу добавлять Сервисы интеграции
SOAP сервисы. Многословны, тяжелы в поддержке (на любой чих надо менять схему XDTO, типы данных и т.д.) Но зато полностью сами себя описывают - и это таки преимущество. Можно получить схему wsdl, и будешь знать какие сервисы есть, какие параметры принимают, что возвращают.
HTTP сервисы - люблю их нежно! быстро в разработке, быстро в обмене. Но вот с описанием API и документацией "наружу" беда. Т.к. ее попросту нет. Зная адрес расположения веб-сервисов, внешняя система никак не может знать, какие параметры она может передать, какие вообще сервисы ей доступны для вызова, и что эти сервисы могут возвращать. Поэтому OpenApi, swagger, вот это вот все.
Так что для разных целей таки разные инструменты будут оптимальными.
З.Ы. - а почему, кстати, нет упоминаний об ODATA? там вообще CRUD можно организовать :)
Гарантию доставки обеспечивает алгоритм. В брокерах он встроенный, учитывает всякие нюансы...
В 1с - надо свой аналог писать каждый раз и самому учитывать нюансы.
Но, брокер - это такая штука, которая может сломаться. Как и 1с.
И все же обмен 1с<->ЧтоТоТам или 1с<->1с - это 2 программы. А через брокер - 3 программы. И это надо поддерживать, и настраивать, и сломаться может уже в трех местах)
Ни в коем случае не отрицаю преимущества брокеров сообщений. И все же они не панацея)
Использовать тяжелые SOAP Только ради самоописания? Потому что было лень документацию сделать?
Поработайте, пожалуйста, с обменами где ресурсов мало, а сообщений обмена - много)
ODATA - а кто ж ее знает? Не нашел там ничего похожего на правила обмена.
HTTP сервисы - присоединяюсь к вашей любви.
А при интеграция с другими системами столкнулся, что у их программеров траблы с соап, а хттп делают быстро.
Не это ли преимущество чттп?)
Я исхожу из того же: хттп проще.
У меня лицензии хттп соединение не съедает. Не путать с веб-клиентом.
Крайне условное преимущество... проявляется в связи с недостатками подготовки коллег из не 1С...
На php мне тут на днях моментом подключение к соап сваяли, например.
На делфи ребята попадались менее подготовленные, под андроид тоже,
но у меня около 80 процентов 1С-1С, а там проблем нет.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1221657
Создание 08.04.20 18:00
Обновление 17.04.20 18:45
Просмотры 27511
Загрузки 0
Рейтинг
105
Комментарии 79
Код открыт Да
Рубрики WEB-интеграция
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
