Многие разработчики, решая задачи обмена данными, используют те технологии, с которыми уже знакомы.
Кто-то лепит обмены через 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 строк кода. Для решения таких сложностей существуют библиотеки и фреймворки.
Но об этом - в следующей серии.
