Как должна выглядеть правильная интеграция. Использование Mule ESB и RabbitMQ с 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, у вас есть единая система, которая управляет десятком систем, с которыми что-то происходит, без интеграционной шины обойтись достаточно сложно. Тогда она сама собой внедряется.

 

Архитектура и инструментарий

Теперь я перехожу к самым интересным слайдам. Про архитектуру я расскажу на практическом примере, я не 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С – это целая жизнь, это создание, не знаю, вселенной практически. Веб-сервис – это просто поток: пришел — ушел в другое место. Все происходит за сотые доли секунды.  В 1С это может занимать 10 — 15 — 20 секунд. Соединения устанавливаются долго, лицензии расходуются, лицензии могут получаться тоже долго. И конечно, безопасность. Естественно у каждого в базе 1С есть какой-нибудь пользователь, который с полными правами и без пароля. Либо у него пароль «123». Еще более продвинутый пароль – «123456». Нельзя это публиковать вовне. Все-таки incorporate.

 

 

 

 

Отладка  

Если вы работаете с http-сервисами, вам понадобятся определенные инструменты.  

 

 

 

Эти три значка просто надо знать. Хотя бы два из них. Первый – точно надо знать. Это Fiddler. Очень крутой мощный http сниффер, который позволяет перехватывать ваш трафик везде, где угодно, расшифровывать https, фильтровать по приложению, отлаживать api – все, что угодно. Если вы через http интегрируйтесь, и все еще его не используете, просто возьмите, скачайте и используйте. Если у вас бухгалтеры хотят использовать http без https, когда-нибудь покажите им, как это все работает, и они больше не будут.

 

 

 

SoapUI – очень удобная штука именно для отладки Soap сообщений. Читает замечательно SDL, позволяет их отлаживать.  Самое главное, что позволяет сделать, – позволяет сделать сервер Soap. Для того чтобы отладить Soap сервер, вам надо написать и клиент, и сервер, не надо этого делать. Можно просто в SoapUI сделать заглушку в SDL и все: пожалуйста, берите, отлаживайте, смотрите, что он пишет.

 

 

 

Postman. Он  круче Fiddler в плане отладки по api. Хорошо работает с заголовками, удобно, отлажено, ничего удобнее, наверное, нет для отладки всего этого дела.

 

 

 

Enterprise Data

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

 

 

 

Incorporate – все это можно использовать. В Incorporate можно использовать интеграционную шину, и ее можно использовать не только для внешней интеграции, как мы Mule ESB. Если у вас типовые прикладные решения, в которых Enterprise Data уже встроена, если вы их регулярно обновляете, у вас одна и та же версия Enterprise Data, то, пожалуйста, эта схема упрощает вашу жизнь при интеграции в несколько десятков раз. Потому что этот подход более правильный. Конечно, там есть много проблем, есть конвертация 3.0, которую пилят-пилят странным образом, есть Enterprise Data, у которого формат меняется каждый месяц. Но рано или поздно мы победим, наверное. И в мире 1С тоже наступит счастье.

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 EDUCATION. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.