Понятия «правильной интеграции» в отрыве от конкретной ситуации просто не существует, поэтому от этого определений лучше отказаться и заменить его интеграцией событийной – эффективной интеграцией, удовлетворяющей требования отдельно взятого проекта. Мы рассмотрим инструменты крупных интеграционных проектов, где требовался регулярный обмен большим количеством информации. Именно такие проекты ставят перед интеграторами самые сложные задачи, а как их решить – проиллюстрируем на реальном примере.
Доверьте интеграцию 1С с любыми системами опытным специалистамВидео выступления эксперта
Инструменты интеграции
Рассмотрим популярнейшие инструменты интеграции на «эволюционной» шкале, отображающей тот порядок, как их осваивают программисты-разработчики.
XLS, CSV
Простейший вариант для несложных интеграций, например, для загрузки табличного документа. Структуру данный формат не поддерживает, в файле может быть только одна таблица или только одна вкладка, а о том, что нельзя настроить связи между несколькими таблицами, даже упоминать не стоит. По этим причинам настраивать интеграцию посредством XLS, CSV придется каждый раз как в первый: один документ-Excel загрузился, но следующий будет иметь другую структуру или даже другой формат (xls, xlsx; csv – может «возникнуть» запятая, точка с запятой или табуляция), поэтому предыдущая настройка не сработает.
COM-коннектор
У данного инструмента интеграции серьезный минус – он разработан под Windows. Когда технологии Linux захватывают все большие объемы рынка, а серверов на Windows становится все меньше (остаются по большому счету только терминальные), W-интеграции все менее применимы на проектах.
Помимо этого COM-коннектор дает «полную свободу действий». Этому радуются разработчики, но не жалуют представители служб безопасности, поскольку 1С не поддерживает передачу хэша при передаче пароля и ком-коннектор передает его в открытом виде.
XML и JSON
Данный инструмент можно назвать продвинутым: поддерживается структура, передаются массивы, штатные функции. Но работа с XML и JSON подразумевает работу с простыми файлами, выгрузка которых при постоянной интеграции требует транспорта, протокола, инфраструктуры и т.д. То есть их нужно версионировать, передать, убедиться, что файл ушел и принимающая система его загрузила… Поэтому любая ошибка здесь чревата потерями и расхождениями данных.
Конвертация 2.0, 2.1
Подходящий механизм для постановки интеграции в масштабах проекта, поддерживающий обмены по расписанию, настройки, правила регистрации и т.д. Но как раз в обмене по расписанию и заложены определенные ограничения: если обмен происходит, например, один раз в секунду, то система будет перегружена, если один раз в 20 минут – возникают проблемы с актуальностью. Также работа с данными при таком обмене чревата возникновением коллизий.
Но это еще не все. Даже задав правила конвертации и выгрузки, проставив реквизиты, можно столкнуться с проблемой логирования и отладки на вкладке «Алгоритмы», которая представляет собой, по сути, массивные куски кода. Если выгрузка происходит, но как-то не так, нужно отлаживать конвертацию. При этом искать ошибку в гигабайтном xml-файле, когда регистрация уже потерта, потому что бизнесу надо работать, – все равно что искать иголку в стоге сена.
WEB/HTTP Services
Самая большая проблема применение этого инструмента – потеря данных из-за «падений» 1С. Помимо этого интеграция с интернет-сервисами требует длительного времени. Также существуют уже знакомые проблемы с логированием и отладкой, но уже в http-формате.
Решением этих проблем может стать интеграционная шина.
Событийная интеграция и интеграционная шина
Основной плюс данной технологии – возможность настроить интеграцию единожды благодаря шине-посреднику.
Например, рассмотрим ситуацию, когда изменился контрагент. Изменения упаковываются в некий пакет (xml/json), и клиент №1 публикует сообщение в шину. Клиенты №2 и №3, подписанные на сообщение, его получают. При этом один клиент может работать постоянно, второй подключаться раз в день, а третий раз в неделю, – на опубликованное сообщение это никак не влияет. Клиент №1 может даже не знать, в какие системы его сообщение отправилось и со сколькими системами он интегрирован. Все это вместо него «знает» шина.
Отметим, что интеграционную шину часто запускают совместно с проектами по MDM, поскольку организовать единую систему, которая управляет десятком других систем, без интеграционной шины фактически невозможно.
Архитектура и инструментарий
Рассмотрим «плохой» пример проекта, где стояла задача интеграции с внешним сервисом в Интернете, который должен был заносить данные в базу 1С. Задача распространенная, так как подобные сервисы становятся все популярнее.
- Сервис «делает» webhooks, которые должны обрабатываться на стороне 1С. Мы создали веб-службу (например, http services, СервисОбмена), а также регистр с настройками (НастройкиОбмена), в котором указали, что именно для данной организации следует писать, в какие регистры и при каких условиях. Все заработало, но что-то не загрузилось.
- В качестве исправления ошибки в базе появился регистр «ОчередьСообщенийОбмена». С появлением этого регистра в модуле сервиса оптимизируются процессы: при обращении к сервису сразу записывается все, что пришло, и далее обрабатывается фоновым заданием. Благодаря этому прекращаются регулярные падения базы. Все работает, но в какой-то момент выгружается «не то».
- В качестве исправления в базе появился регистр «ИсторияСообщенийОбмена». Очередь очистилась, чтобы ускорить работу. Появилась история. В регистре истории организован поиск (даже может быть полнотекстовый). Иногда случались падения, но в целом все работало. Через какое-то время (срок зависит от интенсивности обмена) система стала регулярно зависает «на подумать» при простейших манипуляциях.
- Появился еще один регистр «ИсторияСообщенийОбменаАрхив». Все данные старше месяца стали сливаться в отдельную табличку.
Почему пример «плохой»? Подобная схема может работать даже на крупных проектах, но назвать ее оптимальной нельзя.
Рассмотрим «хороший» пример:
- Настройки и сервис обмена остаются, но внешняя часть меняется на MuleESB;
- Регистр очереди меняется на RabbitMQ;
- «ИсторияСообщенийОбмена» и «ИсторияСообщенийОбменаАрхив» передается в Elastic.
Поподробнее рассмотрим, почему именно эти инструменты стоит использовать.
из мира 1С для ИТ-Директоров
MuleESB
Среда Cloud-сервисов, помимо самих сервисов, может включать мобильные приложения, вебсайты, социальные сети, мессенджеры, которые требуется интегрировать с 1С. MuleESB в этом случае используется как Middleware – некая «прослойка» между Интернетом с cloud-сервисами и Incorporate 1С (если HTTP-сервис 1С все еще опубликован вне локальной сети – об этом будет ниже*). Это делается, чтобы не прибегать к функционально мощной шине, поскольку ESB просто не нужна, если систем «внутри» нее не сотни или хотя бы не десятки.
Mule ESB имеет OpenSource-версию, что определенно является преимуществом. Enterprise-версия, которая при необходимости кластеризуется, имеет удобный веб-интерфейс. В MarketPlace для MuleESB найдется интеграция с огромным количеством разных систем, что может упростить работу в десятки раз.
MuleESB нивелирует «потери», которые могут произойти из-за того, что cloud-сервисы ориентированы на другой профиль нагрузки. Например, пришел запрос, который не соответствует api (скорее всего от робота), и фильтр Payload его «отфутболил». Вы видите только лог, что был прислан webhook и все, а для вас этот webhook мог значить «клиент», «лид», «сообщение о заявке на многомиллионное внедрение», которое вы потеряли.
*Почему нельзя публиковать сервисы HTTP 1С вне корпоративной сети для интеграции со сторонними интернет-сервисами?
- 1С может падать, и, к сожалению, инфраструктура так построена, что из-за падений можно потерять сообщения внешних интернет-сервисов.
- Соединения устанавливаются долго, лицензии расходуются, поскольку сеансовые данные 1С создаются на диске и хранятся в файлах. Подключение одного сеанса к 1С может занимать до 20 секунд.
- Безопасность при такой публикации находится под угрозой, поскольку в базе 1С могут быть пользователи с полными правами и без пароля.
RabbitMQ
RabbitMQ обладает функциональным веб-интерфейсом, позволяет динамически добавлять очереди, проводить мониторинг, кластеризуется, а также поддерживает стабильную, быструю работу.
Но вернемся к сообщению. Оно прошло и разделилось на две части. Часть «ушла» в Elastic, а часть – в RabbitMQ. То есть включение логирования сообщений не вызывает ожидания: мы не ждем логи, поскольку они происходят параллельно, в отличие от того, что происходит в 1С. То есть преимущества протокола AMQP не используются – мы применяем RabbitMQ в качестве удобной и быстрой специализированной СУБД.
Elastic
Elastic, куда ушла вторая часть сообщения, незаменим для хранения истории сообщений и расследования ошибок техподдержкой (если в 1С пытаться найти сообщение «руками».
Инструменты отладки http-интеграций
При работе с http-сервисами могут понадобиться определенные инструменты отладки.
Fiddler – удобный http-сниффер, который позволяет при интеграции через http перехватывать трафик везде, где угодно, расшифровывать https, фильтровать по приложениям, отлаживать api и т.д. Помимо этого он имеет множество функций анализа и фильтрации траффика.
Postman –инструмент отладки http-запросов намного удобнее, чем Fiddler, если они написаны «руками» в плане отладки по api. Отлично работает с заголовками.
SoapUI – удобный инструмент отладки Soap-запросов и не только, с возможностью чтения SDL и их отладки. Позволяет сделать Soap-сервер и отладить его, сделав в SoapUI заглушку в SDL.
Enterprise Data – данный инструмент приближает 1С к принципам событийной интеграции.
Механизм Incorporate предусматривает использование интеграционной шины, причем не только для внешней интеграции. Для типовых прикладных решений, в которых Enterprise Data уже встроена, такая схема интеграции упростит процесс в несколько десятков раз, несмотря на значительное количество проблемных моментов.
консультация эксперта
самые свежие новости 1 раз в месяц
