«1С:Шина» — это программный продукт класса «Сервисная шина предприятия» (в англоязычной терминологии — Enterprise Service Bus, ESB), обеспечивающий обмен данными между различными информационными системами.
В основе работы лежит принцип асинхронного обмена сообщениями между информационными системами, которые взаимодействуют посредством «1С:Шины». Сообщение – блок данных произвольного содержания, который передается от информационной системы — отправителя информационным системам — получателям. Асинхронность подразумевает, что система-отправитель не взаимодействует с системами-получателями, а взаимодействует только с посредником – «1С:Шиной». В свою очередь «1С:Шина» взаимодействует с получателями по мере их доступности и готовности.
«1С:Шина» позволяет настраивать маршрутизацию передаваемых через нее сообщений, то есть по содержимому сообщения определять, какие из взаимодействующих систем должны получить это сообщение. Также есть возможность трансформировать сообщение в процессе доставки. Для описания взаимодействия информационных систем посредством «1С:Шины» предоставляется специальная среда разработки. В ней разработчик может декларативно настраивать маршрутизацию и трансформацию сообщений с использованием встроенного языка.
Для взаимодействия с «1С:Шиной» в платформе «1С:Предприятие» есть механизм сервисов интеграции. Используя возможности этого механизма, разработчик может обеспечить отправку исходящих и обработку входящих сообщений. Высокая скорость (тысячи сообщений в минуту) обмена с «1С:Шиной» обеспечивается за счет встраивания механизма непосредственно в платформу «1С:Предприятие». При этом реализуется гарантированная доставка сообщения: сообщение сохраняется на каждом отрезке пути до системы-получателя.
Помимо взаимодействия с информационными системами на платформе «1С:Предприятие», используя сервисы интеграции, 1С:Шина:
- Позволяет обмениваться по протоколу AMQP для подключения к внешним брокерам сообщений.
- Позволяет обмениваться сообщениями с брокером сообщений Apache ActiveMQ Artemis.
- Поддерживает возможность выполнять HTTP-запросы к внешним системам для получения или отправки данных, вызовов REST API или WEB-сервисов.
Поддерживает обмен сообщениями в виде файлов, сохраненных в файловой системе или на FTP-сервере. Также такие сообщения могут порождаться при изменении файлов в файловой системе или на FTP-ресурсах. Эти возможности позволяют одинаково успешно решать привычные задачи обмена данными и реализовывать более сложные сценарии взаимодействия. «1С:Шина» – серверное решение, которое устанавливается и настраивается отдельно. Администратор может управлять его работой в удобном графическом интерфейсе. Процесс настройки и эксплуатации продукта состоит из нескольких шагов, которые позволяют достаточно быстро и относительно просто выполнить настройку обмена сообщениями, а также контролировать уже запущенные к обмену потоки. В ходе разработки продукта силами нескольких наших партнеров-франчайзи и клиентов были реализованы пилотные проекты внедрения «1С:Шины», с которыми рекомендуем вам ознакомиться по ссылкам ниже:
- Внедрение «1С:Шины» для нужд нефтесервисного холдинга «ТНГ-Групп».
- Внедрение продукта «1С:Шина» в Тамбовском государственном университете им. Г.Р. Державина.
- Использование «1С:Шины» в компании «Альфа партнер».
- Внедрение продукта «1С:Шина» в сети «Магазин постоянных распродаж».
Участники пилотных проектов отметили следующие преимущества:
- Тесная и удобная интеграция с системами на платформе «1С:Предприятие» при возможности работы с другими внешними приложениями.
- Простая установка и настройка.
- Понятный интерфейс и возможность мониторинга доставки сообщений.
- Отправитель не зависит от состояния получателей.
- Гарантированная доставка:
- повтор доставки при отсутствии подтверждения;
- хранение до доставки.
- определение множества адресатов сообщения.
Содержание- Заметки из Зазеркалья
- Данная статья является анонсом новой функциональности. Не рекомендуется использовать содержание данной статьи для освоения новой функциональности. Полное описание новой функциональности будет приведено в документации к соответствующей версии. Полный список изменений в новой версии приводится в файле v8Update.htm.
- Продукт «Интеграционная шина»
- Подключение 1С:Предприятия к «Интеграционной шине»
- Пример сценария интеграции
- Преимущества нашей «Интеграционной шины»
- Как должна выглядеть правильная интеграция. Использование Mule ESB и RabbitMQ с 1С
- Вместо предисловия
- Типы интеграции
- Архитектура и инструментарий
- Отладка
- 🔍 Видео
Видео:Использование 1С:Шина для обмена данными в распределенной базе 1С из 120 узловСкачать
Заметки из Зазеркалья
Видео:Обмен данными с помощью продукта «1С:Шина» на практическом примере - 28.07.2022Скачать
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.Многие наши клиенты используют в своём бизнесе, помимо продуктов 1С, и другие информационные системы от других производителей. Вполне естественным желанием таких клиентов является обеспечить эффективное взаимодействие этих систем.
Примеры сценариев интеграции:
- Офис отправляет в магазины и на сайт изменения в прайс-листе. Приложения, обслуживающие офис, сайт и магазины, могут быть как от 1С, так и от других производителей.
- Накладные отправляются из офиса в магазины автоматически по мере утверждения. В магазине накладные доступны пользователю для работы.
Консолидированная по магазинам информация по остаткам товаров отправляется из офиса в магазины автоматически по расписанию или по требованию. Эта же информация отправляется из магазинов в офис для консолидации в ответ на запрос из офиса остатков автоматически при получении запроса.
Видео:1С ШИНА. ШИНА ДАННЫХ 1С. УСТАНОВКАСкачать
Продукт «Интеграционная шина»
Для организации взаимодействия систем предлагается следующая последовательность:
- Разработчик описывает интеграцию систем в специализированном редакторе, используя простую графическую нотацию.
- Маршрут движения сообщений представляется направленным графом, который показывает, как сообщения передаются от источников к назначениям.
- При необходимости можно определить сложный алгоритм маршрутизации сообщений или трансформировать сообщение при помощи процедуры на встроенном языке.
- Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система (такие системы называются участниками взаимодействия).
- Полученное описание сохраняется в специальном объекте Процесс интеграции.
- Определяются параметры Процесса интеграции, значения которых будут определены во время исполнения (пути, адреса сервисов и пр.).
- Созданные разработчиком Процессы интеграции разворачиваются на сервере «Интеграционной шины».
- Администратору сервера доступен графический интерфейс управления «Интеграционной шиной», в котором:
- Задаются значения дополнительным параметрам Процесса интеграции
- Определяются правила подключения Участников взаимодействия к серверу «Интеграционной шины» и способ их участия в процессах интеграции
- Запускаются Процессы интеграции и начинают доставлять сообщения
- Останавливаются Процессы интеграции
- Доступны данные мониторинга работы Процессов интеграции: количество обработанных сообщений, ошибок и пр.
При создании Процесса интеграции разработчик не должен знать точное число систем-участников интеграции. Вместо этого он оперирует понятием группа участников, которое объединяет произвольное количество участников, взаимодействующих с «Интеграционной шиной» единообразно. Во время исполнения администратор определяет, к каким группам относится конкретная система-участник, и для этого участника динамически выделяются необходимые ресурсы.
Видео:1С:Шина — интеграция с внешними ИС, формат Enterprise Data, преобразования CSV/JSON/XDTO — RTD2023Скачать
Подключение 1С:Предприятия к «Интеграционной шине»
Для поддержки асинхронного обмена сообщениями в платформе 1С:Предприятие версии 8.3.17 добавлен механизм сервисов интеграции. Обмен сообщениями происходит по каналам, организованным на сервере. Канал – это однонаправленный поток сообщений от отправителя к получателю. Сообщения в канал помещаются последовательно отправителем и последовательно доставляются получателю. Сообщения разных каналов обрабатываются и доставляются параллельно. Сообщение доставляется в шину только в том случае, если зафиксирована транзакция, в которой это сообщение отправлено.
- Сообщения, отправленные в один канал в определенной последовательности, будут получены в той же последовательности.
- Любые два сообщения, полученные из разных каналов в определенной последовательности, не обязательно будут обработаны в этой же последовательности, так как обработка сообщений из разных каналов может идти с разной скоростью.
Механизм сервисов интеграции в 1С:Предприятие не является альтернативной механизмам планов обмена, так как отвечает только за транспортировку сообщений, а не за формирование исходящих и интерпретацию входящих сообщений.
Взаимодействие с «Интеграционной шиной» выполняется с гарантированной доставкой сообщения, что означает:
- Отправляемое в «Интеграционную шину» сообщение сохраняется в информационной базе до тех пор, пока от «Интеграционной шины» не будет получено подтверждение того, что сообщение им получено.
- Система 1С:Предприятие будет выполнять попытки доставить сообщения «Интеграционной шине», пока не будет получено подтверждение получения сообщения или сообщение не устареет (у сообщения может быть установлен «срок годности»).
- При получении сообщения от «Интеграционной шины» это сообщение сохраняется в информационной базе, и только после этого «Интеграционной шине» подтверждается получение сообщения.
Видео:Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать
Пример сценария интеграции
Офис отправляет в магазины и на сайт изменения в прайс-листе.
Схема содержит три группы участников: «Офисы», «МагазиныСоСтарымПО» и «МагазиныНа1С». В группе «МагазиныНа1С» объединены участники, которые используют для автоматизации системы на платформе 1С:Предприятие. В группе «МагазиныСоСтарымПО» собраны участники, которые используют ПО других производителей.
В момент изменения прайс-листа в офисе формируется сообщение, содержащее актуальный прайс-лист в формате EnterpriseData. Это сообщение отправляется в канал «ИзОфисов».
В узле «ДляВсех» все сообщения из канала «ИзОфисов» маршрутизируются по трем направлениям:
- Для передачи магазинам, использующим старое ПО, в формате JSON. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляМагазинов». Полученный JSON отправляется в канал «ДляМагазиновСоСтарымПО».
- Для передачи магазинам, использующим ПО 1С, сообщение в исходном виде отправляется в канал «ДляМагазиновНа1С».
- Для публикации на сайте. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляСайта». Полученный JSON отправляется на сайт HTTP запросом в узле «НаСайт».
При настройке такого процесса интеграции разработчику совершенно не важно, сколько магазинов каждого вида будет участвовать в интеграции.
Видео:Интеграционная шина предприятия. ЛОЦМАН-1С. Конструкторский составСкачать
Преимущества нашей «Интеграционной шины»
После знакомства с «Интеграционной шиной» может возникнуть естественный вопрос: рынок ПО класса ESB достаточно обширен, на нем представлено немало достойных продуктов, в том числе и бесплатных; зачем же фирме «1С» делать ещё один продукт, не изобретаем ли мы велосипед?
Конечно, перед тем, как принять решение разрабатывать «Интеграционную шину», мы задались тем же вопросом. И ответили себе на него так — да, делать продукт сто́ит, потому что:
- Мы постарались сделать наш продукт максимально простым и удобным в использовании.
- Мы сделали интеграцию нашего продукта с приложениями 1С максимально гладкой.
- «Интеграционная шина» от 1С легка в освоении для разработчиков 1С и позволит клиентам во многих случаях для настройки процессов интеграции обходиться усилиями существующих ИТ-специалистов (партнера 1С и/или своего ИТ-отдела, обслуживающего клиента).
- Наш продукт будет органично вписываться в экосистему 1С и позволит решить нашим клиентам задачи своего бизнеса наиболее эффективным способом.
Мы планируем развивать продукт, в частности, увеличивать количество способов взаимодействия с внешними системами, улучшать средства мониторинга, ввести возможность добавлять сервисы интеграции через расширения, устанавливать связь сервисов интеграции и планов обмена.
Мы планируем этап бета-тестирования «Интеграционной шины» и будем рады помощи партнеров и клиентов. Чтобы участвовать в бета-тестировании продукта нажмите зелёную кнопку «Пробовать» в начале статьи.
Видео:DevCon.3 11. Пример интеграции информационных систем через 1С:ШинуСкачать
Как должна выглядеть правильная интеграция. Использование Mule ESB и RabbitMQ с 1С
Видео:1С:Шина–программное обеспечение для обмена данными между информационными системамиСкачать
Вместо предисловия
Для начала скажу, что правильной или неправильной интеграции, наверное, не бывает. Бывает только под конкретную задачу. Если задача сложная, то мой подход подойдет, если вам надо загрузить эксельник в табличный документ, то это уже другая интеграция. Я постараюсь рассказать о том, как избежать большинства проблем, которые у вас возникают на сложных, больших интеграционных проектах, которые идут постоянно, где регулярный обмен и может быть много ошибок.
Видео:«1С:Шина»: технология и использование на предприятии. Вебинар Первого Бита совместно с 1ССкачать
Типы интеграции
Прежде, чем рассказывать о том, как правильно и хорошо делать, я расскажу о том, какие есть типы интеграции, какими мы обычно пользуемся, и что в них плохого.
Каждый разработчик, с тех пор как начинает программировать и до получения Senior Developer, проходит определенные стадии. Все мы, наверное, начинали с xls и csv.
Это классика жанра. Приходит бухгалтер, просит загрузить ей что-нибудь в табличный документ. Хорошо, пожалуйста, вот Excel, я загрузил, все хорошо. Следующий Excel уже другой, все сломалось, и ничего не работает. Это может быть не xls, а csv.
Структуры нет. Конечно, объединение ячеек в Excel все знают, все прикольно, все замечательно. Но табличка может быть только одна либо только одна вкладка. Номер заказа, номенклатура не структурированы.
Что касается связей. Все понимают, что обычно мы грузим реляционную структуру. А реляционная структура подразумевает, что есть не одна таблица, а несколько, и между ними есть связи. В Excel и csv это никак не отразить.
У Excel и csv могут быть разные форматы. У вас может быть xls, xlsx; csv вы можете разделить запятыми, точкой с запятой, а можете поставить табуляцию. Это замечательно, но работает каждый раз по-разному.
В общем, этот этап все проходят достаточно быстро, понимают, что много минусов.
Что дальше делает разработчик? Он открывает желтую книжечку. В желтой книжке написано «ком-коннектор». Здравствуй, ком-коннектор!
Это замечательный инструмент интеграции. Но замечательный он, скорее, для разработчика. Неудобен он только одним – он под Windows. Если еще 5 лет назад мы смеялись над 1С на Linux, то сейчас видим, что серверный мир упорно и плотно движется в Linux. И я думаю, что вскоре серверов на windows будет мало. А если они и останутся, то только терминальные. MacOS завоевывает десктопы. Все любят ноутбуки, все приучились к айфонам, и маковский интерфейс подкупает. Поэтому мы стали думать и о MacOS, и о Linux, и виндовые интеграции уже применимы далеко не на всех проектах.
С ком-коннектор полная свобода творчества. Что хотите, то и делайте. Хотите в одной базе что-нибудь сделайте, хотите в другой базе. Можете во второй базе что-то удалить, можете добавить. Залезть в другой регистр, посмотреть. Замечательно для разработчика. Разработчики это безумно любят. Не любят это обычно менеджеры, а еще больше это не любят «безопасники». Они просто ненавидят ком-коннектор. Те, кто не знает, что это такое, говорят, просто код какой-то написан, ладно. А те, кто знает, понимает, что это пароль, пароль в открытом виде, конечно же, он написан в коде, в коде его посмотреть никто не может. Поэтому у кого-то он сохранен в отдельном справочнике, и даже прикрыт звездочками. Вот если пароль прикрыт звездочками, это уже next level! На самом деле, конечно, все понимают, что 1С не поддерживает передачу хэша при передаче пароля, и мы его все равно передаем в открытом виде.
Почти человеческая интеграция – это когда разработчик прочитал уже не желтую книжечку, а что-нибудь в интернете. А там написано, что xml и json – это хорошо. И зачем через ком коннектиться, если можно выгрузить в xml и загрузить из xml? Уже есть структура, вроде, можно передать массивы, можно что-то структурировать, есть штатные функции, все круто.
Но xml и json – это всего лишь файлики. Когда вы выгрузили файлик и у вас постоянная интеграция, вы понимаете, что файлик нужно версионировать, нужно убедиться, что он загружен, его нужно как-то передать, убедиться, что он передан, убедиться, что вторая система его загрузила, что загрузила его успешно. И это не очень хорошо.
Следующий этап – конвертация.
Говорю о конвертации 2.0, 2.1, потому что 3.0 – это тот еще специфичный зверь, и не совсем конвертация. Не знаю, почему эти два решения назвали одинаковым словом. Вторая конвертация – это уже человеческая интеграция, это уже как бы Homo Sapiens, это то, чем можно пользоваться на проектах. У нас есть замечательный BSP, проверенный временем и делом, есть обмены по расписанию, есть настройки, есть правила регистрации – все, что нужно. И интеграцию на конвертации организовать уже можно.
Но мы ограничены обменом по расписанию. Первый вопрос, который возникает, а сколько – один раз в минуту или в час, или может быть один раз в 10 минут, или может быть один раз в секунду. Если один раз в секунду, то система уже перегружена. Если один раз в 10 минут, нам мало. А когда у нас данные, у нас возникают коллизии: мы здесь поменяли, в другом месте, и опять что-то не так.
Опять же слишком много свободы творчества. Да, конвертацию открываем, все круто. Там правило конвертации, правило выгрузки, реквизиты поставлены, все круто. Но до того, как мы откроем последнюю вкладку «алгоритмы», где огромные куски кода, очень здоровые. Как-то оно все выгружается, может выгружаться вообще не так, как вы думали.
И еще – каждый, кто хоть раз конвертацию отлаживал, знает, как сложно найти ошибку в этом гигабайтном xml файлике, в котором очень много всего, и где-то в серединке скрылась ошибка, что-то случилось. А регистрация уже потерта, потому что бизнесу надо работать. В общем, то ещё развлечение!
Разработчик идет дальше. Он прочитал больше книжек, и вот так выглядит разработчик, который освоил интеграцию через web/http services.
Вот так он себя чувствует!
Но недолго. Первое падение возникает достаточно быстро – когда вы теряете данные. 1С-ка упала, вы пожимаете плечами, мол, это бывает.
Потом возникают варианты, когда интегрируемся с интернетовскими сервисами, длительное подключение, особенно если УТ 10.1, в которой при подключении даже по web-коннектору целая жизнь происходит,
вселенные создаются. Есть те же самые проблемы с логированием и отладкой: что-то там по http гуляет, вы не видите, оно иногда загрузилось, иногда не загрузилось. В общем, радость длится недолго.
Что нужно сделать, чтобы стать нормальным разработчиком, который решил все эти проблемы? Дальше рассмотрим.
Поскольку мой доклад все-таки про событийную интеграцию, я не могу обойти теорию. Потому что не все еще, наверное, прочитали, увидели, услышали, что такое событийная интеграция, интеграционная шина. Я буквально в нескольких словах расскажу.
Типичная, наверно, картинка.
Эта картинка из интернета, ничего в ней нового. Один публикует сообщение, шину, и двое, допустим, подписались на сообщение. То есть где-то в одной системе изменили контрагента, сразу при изменении в фоне это все упаковалось в некий пакет в xml, в json, попало в шину. После того, как клиент записал контрагента, отправил в шину, дальше ему все равно, дальше хоть потоп, его не интересует, загрузили они, не загрузили. У вас один клиент может работать мегабыстро. Второй может раз в день включаться, а третий – может находиться на том краю света. Этим всем занимается уже интеграционная шина. Тому, кто публикует сообщение, это все абсолютно неинтересно. Более того, он даже может не знать, в какие системы его сообщение пошло. У нас появилась новая система, допустим, там нужен справочник контрагентов. Ok, подписались. И теперь сюда приходят контрагенты. Тот, кто писал изначальную интеграцию, даже может не знать, со сколькими системами он интегрировался.
Это круто. Когда у вас есть интеграция, о которой вы даже не знаете. То есть вы просто сделали разово, а все остальное работает. Для этого и делаются интеграционные шины.
И еще я скажу, что интеграционные шины, как проект, очень часто идут параллельно с проектами по MDM. Когда у вас организация выросла до такой степени, что вам нужен Master Data Managemen, у вас есть единая система, которая управляет десятком систем, с которыми что-то происходит, без интеграционной шины обойтись достаточно сложно. Тогда она сама собой внедряется.
Видео:Интеграционная шина данных | 1C ERP интеграция | Связь между системамиСкачать
Архитектура и инструментарий
Теперь я перехожу к самым интересным слайдам. Про архитектуру я расскажу на практическом примере, я не IT-евангелист, который вам что-то продает, что очень модное и крутое. Я расскажу, как я делал интеграцию, какие были проблемы, как я их решал, как я, к своему стыду, их решал 2-3-4 раза до того, как понял, что их можно решать по-нормальному.
Реальный случай. Пришли менеджеры и говорят, что им надо интегрироваться с каким-то внешним сервисом. Он дисконтные карточки выпускает, контрагентов заводит, еще что-то делает. То есть какой-то сервис в интернете что-то пишет к нам в базу 1С. Таких сервисов в интернете становится все больше и больше, поэтому с этими задачами мы будем сталкиваться чаще и чаще.
Эта штука в интернете умеет делать вебхуки. А вебхуки надо обрабатывать на стороне 1С. Вроде, все круто, мы это умеем делать: делаем http services, делаем какой-то регистр с настройками, в котором говорим, что это для этой организации, надо писать в такие-то регистры при таких-то условиях.
Все сделали, все хорошо. Денечек живем, может быть, два. Через три дня к нам приходит менеджер примерно с таким лицом. Что-то мы не загрузили.
Мы оправдываемся, мол, пилотный проект, все поправим, исправим, все сделаем, все будет хорошо. Менеджера отпаиваем кофе или чем-то покрепче. Она уходит. А в базе появляется регистр примерно следующего содержания «Очередь Сообщений Обмена». В скольких базах я этот регистр видел! В том или ином виде названный, но он всегда присутствует. И он даже называется всегда «Очередь». Но по слову «очередь» ни до кого сразу, в том числе и до меня, к моему стыду, не доходит, что надо посмотреть куда-то еще.
Ок. В базе появляется регистр «Очередь Сообщений Обмена». Теперь в модуле сервиса не происходит целой жизни, не создаются вселенные, не проводятся пачки документов. При обращении к сервису сразу записывается все, что пришло. Дальше это все обрабатывается фоновым заданием. То есть у нас все прекращает падать, по крайней мере, регулярно.
Мы живем недельку, две, три. И живем спокойно. Через пару недель приходит опять менеджер. Говорит, что мы не то что-то загрузили. Им прислали 300 рублей, в мы загрузили 200, клиент недоволен, скандалит.
Менеджера, конечно, мы успокаиваем, даем ей сто рублей. И как бы все хорошо. Менеджер уходит.
Мы немножко чешем репу, и в базе появляется регистр «История Сообщений Обмена». Тоже типичная ситуация: очередь очищается, иначе это будет все жестко тупить, появляется история. Плюс появляется некий инженер техподдержки, который в этой истории может покопаться и ответить на вопросы менеджера, которых у него к этому моменту появилось немало. Потому что компания растет, клиентов становится больше, проблем еще больше. Поэтому в регистре истории есть поиск, он даже может быть полнотекстовым, иногда валится, но все работает.
Так мы живем примерно месяц, два, три – в зависимости от интенсивности. Через три месяца к нам приходит уже не менеджер, к нам приходит наш несчастный сотрудник техподдержки. Вот с таким лицом.
Он будет говорить: «Парни, я все понимаю, но сделайте что-нибудь, я заколебался уже: нажал кнопочку и жду час». В принципе сотрудники поддержки не сразу приходят, они терпеливые ребята, но когда ждать надо час, они уже приходят. Его мы тоже отпаиваем, он уходит.
А что делают 1С-ники? Решение на самом деле типовое: появляется еще один регистр «История Сообщений Обмена Архив». Классика жанра. То есть все, чему больше месяца, мы убираем отдельно в табличку. Вроде, радуемся, вроде, живем.
Я, может быть, смеюсь, что это такое решение прикольное, глупое. На самом деле эта штука работает, она работает не на одном проекте, не на двух, не на десятке. Оно работает даже на крупных проектах. И в принципе это работать может, и работать будет нормально. С этим можно жить, особо проблем не испытывать. Но зачем?
Есть вариант лучше. При котором мы не будем проходить весь этот сложный путь и не будем дальше мучиться, проблем будет намного меньше.
Это уже наш кейс. Настройки и сервис обмена остается, но его внешняя часть заменится на Mule ESB. Регистр очереди заменяется на RabbitMQ. «Историю Сообщений Обмена», как и «Историю Сообщений Обмена Архив» сам Бог велел положить в Elastic.
Вот такой инструментарий получился в нашем кейсе. У вас он может быть другим. Я объясню, почему, мы выбрали именно так, хотя это не принципиально. А дальше поговорим, почему это в 1С не очень хорошо делать.
Примерно так выглядит типичная интеграция в Mule ESB.
В HTTP сервис приходит сообщение, дальше у вас фильтр by Payload. Кстати, очень интересная штука. Если у вас сервис опубликован вовне, вас кто-то наверняка попытается просканировать, закидать вас запросами – в интернет-сервисах роботы иногда любят это делать. 1С из-за этого иногда ложится. Все люди делятся на две категории: у кого сервисы 1С не опубликованы вовне, и у кого они все еще опубликованы вовне. Так вот если у вас сервис 1С все еще опубликован вовне, то про этот фильтр by Payload надо знать. Если к вам пришел запрос, который не соответствует вашему api, а от робота он, скорее всего, не соответствует, то он отобьется. Уже на уровне шины происходит все быстро и замечательно.
Что здесь делает Mule ESB?
Mule ESB мы используем, скорее, как Middleware, как некую прослойку, не используя мощный функционал шины, потому что у нас не столько систем внутри – не десятки, не сотни. Функционал шины нам не нужен настолько. А нужен функционал Middleware, именно прослойки между интернетом, богатыми сервисами и 1С.
На картинке: слева – это у нас cloud, а справа – incorporate. Incorporate может быть даже не 1С, но cloud сервисы построены на других технологиях, они ориентированы на другой профиль нагрузки. Cloud сервис, если что-то произошло, вам легко пришлет вебхук, потому что его не интересует, что у вас происходит, он вам покажет лог, что вебхук был прислан и все. А для вас этот вебхук значит «клиент», «лид». Может быть, он написал вам заявку на миллион, например, «хочу внедрить ERP на сайте». А вы это сообщение потеряли. Там же могут быть мобильные приложения, которые у вас существуют. Там же могут быть вебсайты, которые интегрируются с 1С, социальные сети, мессенджеры… Короче, так или иначе вы с какой-то внешней штукой будете интегрироваться. Потому что, к сожалению или к счастью, мир идет в облака, и облачных сервисов становится все больше и больше. И внутри корпораций их надо использовать.
Почему Mule ESB? Был некий market research. Когда мы проанализировали, поняли, что, наверное, он наиболее развитый среди open source. Есть Enterprise версия, которая при необходимости кластеризуется, имеет красивый веб интерфейс. Есть open source версия, которая также замечательно работает без особых проблем. В marketplace для Mule ESB найдется интеграция с кучей разных систем, которые не российские, но, тем не менее, это может упростить в десятки раз работу.
Далее. Сообщение прошло, на картинке это два служебных кубика. Дальше оно разделилась на два, заметьте. Часть пошла в Elastic, а часть – в RabbitMQ. То есть, во-первых, сообщение не ждет логи, они происходят параллельно, и ожидания не происходит от того, что мы включили логирование. В отличие от того, что мы имеем в 1С.
«Кролик». Зачем мы взяли «кролика»?
В принципе можно взять какой-то regis, туда закидывать информацию. Для этого любое хранилище подойдет. Но тут вопрос «а зачем»? Если есть испытанная штука, есть богатый веб интерфейс, можно динамически добавлять очереди, есть какой-то мониторинг, кластеризуется, стабильная, быстрая и все круто?
AMQP, конечно, да…Наверное, «кролик» внедряется во имя AMQP. Когда у вас крупный проект, если где-то возникло событие, оно тут же, мгновенно пошло и возникло в другой системе. Это очень быстро, очень «скоростно». И во имя этого AMQP протокола в принципе «кролик» и делался. Нам он не сильно нужен. А городить что-то на сервере 1С своими AMQP тоже не хочется. Поэтому мы используем его вот так. «Кролик» из-за этого, конечно, расстроен, он огорчен, ему грустно. Но ему некуда деваться, работает он стабильно и хорошо.
Elastic – это вторая часть сообщения. На начальном этапе он дает отличный эффект для техподдержки. Если кто-то когда-нибудь в 1С пытался найти руками сообщение (упорно и усиленно), то через Elastic он это сделает быстро.
Это моё лицо, когда я узнаю, что кто-то публикует 1С-сервисы вовне.
Нельзя публиковать сервисы 1С вовне! Да, у нас платформа хорошая, быстрая, гибкая, развивается. Внутри замечательно используется, но вовне – нет. Потому что 1С может падать. Это факт. К сожалению, инфраструктура так построена, что могут быть простои, могут быть падения, а мы не можем терять сообщения от внешних интернет-сервисов.
У 1С есть такая замечательная штука, как сеансовые данные, которые хранятся в файлах, на диске создаются. Подключение одного сеанса к 1С – это целая жизнь, это создание, не знаю, вселенной практически. Веб-сервис – это просто поток: пришел — ушел в другое место. Все происходит за сотые доли секунды. В 1С это может занимать 10 — 15 — 20 секунд. Соединения устанавливаются долго, лицензии расходуются, лицензии могут получаться тоже долго. И конечно, безопасность. Естественно у каждого в базе 1С есть какой-нибудь пользователь, который с полными правами и без пароля. Либо у него пароль «123». Еще более продвинутый пароль – «123456». Нельзя это публиковать вовне. Все-таки incorporate.
Видео:Мониторинг и работа над ошибками в шине данных DATAREON ESB на примере систем 1ССкачать
Отладка
Если вы работаете с http-сервисами, вам понадобятся определенные инструменты.
Эти три значка просто надо знать. Хотя бы два из них. Первый – точно надо знать. Это Fiddler. Очень крутой мощный http сниффер, который позволяет перехватывать ваш трафик везде, где угодно, расшифровывать https, фильтровать по приложению, отлаживать api – все, что угодно. Если вы через http интегрируйтесь, и все еще его не используете, просто возьмите, скачайте и используйте. Если у вас бухгалтеры хотят использовать http без https, когда-нибудь покажите им, как это все работает, и они больше не будут.
SoapUI – очень удобная штука именно для отладки Soap сообщений. Читает замечательно SDL, позволяет их отлаживать. Самое главное, что позволяет сделать, – позволяет сделать сервер Soap. Для того чтобы отладить Soap сервер, вам надо написать и клиент, и сервер, не надо этого делать. Можно просто в SoapUI сделать заглушку в SDL и все: пожалуйста, берите, отлаживайте, смотрите, что он пишет.
Postman. Он круче Fiddler в плане отладки по api. Хорошо работает с заголовками, удобно, отлажено, ничего удобнее, наверное, нет для отладки всего этого дела.
Напоследок скажу, что в 1С не все так плохо. В 1С все хорошо, замечательно, мы движемся в правильную сторону. У нас есть Enterprise Data, которая нас приближает к той самой событийной интеграции.
Incorporate – все это можно использовать. В Incorporate можно использовать интеграционную шину, и ее можно использовать не только для внешней интеграции, как мы Mule ESB. Если у вас типовые прикладные решения, в которых Enterprise Data уже встроена, если вы их регулярно обновляете, у вас одна и та же версия Enterprise Data, то, пожалуйста, эта схема упрощает вашу жизнь при интеграции в несколько десятков раз. Потому что этот подход более правильный. Конечно, там есть много проблем, есть конвертация 3.0, которую пилят-пилят странным образом, есть Enterprise Data, у которого формат меняется каждый месяц. Но рано или поздно мы победим, наверное. И в мире 1С тоже наступит счастье.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
🔍 Видео
Интеграция 1С с СУБД при помощи сервисной шины данных DATAREON ESBСкачать
1С:Шина: презентация продукта, примеры интеграцииСкачать
Владислав Маковеев. Интеграция через 1С:ШинуСкачать
DevCon2020 8. Сервисы интеграции и 1С:ШинаСкачать
Принятие решений на основе анализа данных и их визуализации с помощью 1C:MDM, 1С:Шина и 1С:АналитикаСкачать
Приемы разработки и практический пример на «1С:Шина» — 1C-RarusTechDay 2022Скачать
Выбираем решение для быстрой и надежной интеграции систем «1С» (Вебинар 04.12.2019)Скачать
Интеграционная шина предприятия. Структура правила экспортаСкачать
