Привет всем гуру всемогущих языков программирования! Меня зовут Иван, я возглавляю backend-направление в компании SimbirSoft. Для своей первой статьи на Хабр решил поднять вопрос, как правильно сделать интеграцию с любой платформой 1С, используя Java, С# и другие языки программирования.
Пару слов обо мне и моем опыте работы с вышеупомянутым стеком. В свое время я писал всевозможные интеграции со стороны 1С. Около трех лет приходилось решать интеграционные вопросы по взаимодействию с производственными системами (MES), системами управлениями складом (WMS), системами управления транспортом и даже со счетчиками учета электроэнергии. Но судьба забросила меня в мир Java, и мои взгляды на разные аспекты интеграции с 1С-платформами сильно изменились.
В этой статье я расскажу о своем опыте интеграции и сложностях, которые могут при этом возникнуть. Я искренне считаю, что множества проблем можно избежать, если специалист представляет, как работают механизмы интеграций в обеих платформах. Рассмотрим на примере Java, но эти подходы доступны и для других языков. Про интеграцию подробно рассказано в книге «Технологии интеграции 1С:Предприятия 8.3» Елены Хрусталевой. В этом материале я приведу несколько методов взаимодействия, плюсы и минусы подходов и их применимость для разных компаний. Помимо этого, рассмотрю самый удобный, на мой взгляд, метод, который не представлен в этой книге. Статья будет полезна специалистам 1С, Java-разработчикам, а также проджект-менеджерам и владельцам продуктов.
Требования к корпоративным системам
Представим, что нам нужно решить задачу по передаче данных из любой платформы 1С (например, «Зарплата и Кадры») в приложение, которое написано на Java, или наоборот. Решив вопросы надежности, скорости обмена, различия между платформами и расширяемости, детализируем наши требования.
Надежность
Поскольку все интеграционные решения выполняются в разных корпоративных системах и передаются по каналам связи, в такой распределенной среде всегда присутствует ряд недостатков. При доставке данных на каждом из этапов может возникнуть риск потери и/или задержки сведений, что, вероятно, неприемлемо в корпоративной среде.
Классический пример: обмен между системой, оформляющей продажи (обычно 1С), и системой управления складом (WMS), которая контролирует остатки на складе. Если данные об остатках будут приходить не оперативно или в неправильной последовательности, то это может привести не только к неправильным данным в системе продаж, но и к финансовым потерям бизнеса.
Скорость обмена
Каждый из вас наверняка сталкивался с медленными интеграциями — например, на сайте государственных услуг, когда обмен документами (в большинстве случаев это определенный пакет данных) между корпоративными системами может занимать до суток. С одной стороны, я очень рад, что такие интеграции есть, но скорость обмена — точки роста сервиса. В корпоративных системах она имеет критическую важность.
В качестве примера приведу скрин со всеми любимых Госуслуг. Портал сообщает, что данные появятся, но вопрос — когда?
Различия между платформами
Говоря о методах интеграции, нельзя не учитывать различия между 1С и Java. По моему опыту взаимодействия с обеими платформами и отзывам коллег, бывают ситуации, когда специалисты 1С качественно работают с бизнес-требованиями, но недостаточно погружаются в нюансы работы 1С-платформы с базой данных, того, что последует за открытием REST/SOAP API из 1С для внешних пользователей. К слову, само понятие бесперебойной работы 24/7 также сложно реализуемо для платформы 1С, так как по объективным причинам с регулярностью раз в пару недель выходят регламентированные обновления, которые временно останавливают работу 1С.
В мире Java — другие проблемы. Ребята, как правило, неплохо умеют работать с базами данных (ORM тоже, конечно, надо применять с умом), имеют более широкий кругозор в вопросах взаимодействия с распределенными системами. Однако когда Java-разработчики слышат об 1С, у них возникает стойкое чувство пренебрежения. А причина — незнание или нежелание знать, насколько 1С крутая платформа, какие решения она может предложить и какой уровень абстракции предоставляет, хотя там нет классов и наследования.
Что с этим делать? Освоить возможности платформы. Читайте документацию и изучайте примеры кода. Общайтесь с 1С-специалистами — они расскажут, как использовать платформу в разных ситуациях. Наконец, не забывайте, что любая технология имеет свои достоинства и недостатки, и важно уметь обращаться к ней в нужный момент.
Расширяемость
Когда речь идет о корпоративных решениях, изменения в их коде и данных неизбежны: если система не меняется, бизнес, скорее всего, движется не туда. Зачастую изменения в одной системе затрагивают работу другой. При этом крайне желательно, чтобы изменения в одной не привели к глобальным корректировкам в другой.
Пример: ситуация, когда в базе данных произошло изменение, которое не было полностью отражено в коде системы. В частности, если был добавлен новый тип продуктов в базу данных, но соответствующие изменения не были внесены в код, который отображает эти продукты на сайте. В результате клиенты могут видеть продукты, которые купить нельзя, поскольку они не были полностью реализованы в системе. Это может серьезно повлиять на лояльность клиентов и привести к снижению прибыли компании. В этом случае необходимо внести соответствующие изменения в код системы, чтобы он отображал все типы продуктов, которые есть в базе данных.
3 самых популярных метода взаимодействия: плюсы, минусы, области применения
Как я уже упоминал выше, с ними можно подробнее познакомиться в книге. Я рассмотрю плюсы и минусы решений и предложу наиболее удобный, на мой взгляд, метод интеграции. Умышленно упущу метод обмена с помощью механизмов «планов обмена», поскольку реализация на стороне Java — трудозатратный процесс. Хотя, если ваши бюджеты не ограничены, рассмотрите этот метод факультативно.
Способ 1. Файловый обмен
Это самый простой и понятный метод обмена. Он пришел к нам еще из времен первых компьютеров, расположенных на разных серверах сервисов, а значит, в этом случае в правильной корпоративной среде будет необходимо также и файловое хранилище.
Такой подход может подойти, когда наше приложение (1С или Java — неважно) закрыто и мы не можем его изменить. При этом заранее определены форматы данных. В этом случае у нас не будет выполняться требование расширяемости. Если проекты открыты для изменения, можно столкнуться с со следующими проблемами:
Приложение, которое записывает данные в файл, должно контролировать этот процесс. Оно может быть недоступно по разным причинам, а если важна последовательность сообщений, то приложение должно контролировать и этот процесс. Понимаю ваши возражения: в файл можно добавить номер пакета с данными и контролировать. Но это не всегда возможно и часто неудобно. Например, если мы говорим о файловой системе, там может быть ограничение на имя файла или размер данных, которые не позволяют добавлять номер версии.
Также, если это приложение работает в режиме реального времени, то может быть неудобно обрабатывать каждый пакет данных и проверять его номер. В таких случаях можно выбрать другие методы контроля процесса записи в файл. Например, приложение может использовать очередь сообщений, чтобы гарантировать последовательную обработку данных. Также можно использовать механизмы блокировки, чтобы предотвратить одновременную запись в файл из разных потоков или процессов.
Кроме того, приложение должно быть способным обрабатывать ошибки записи в файл и перезапускать процесс записи в случае неудачной попытки. Для этого может быть использован механизм повтора попыток записи или механизм резервного копирования данных. В целом, каждый случай может требовать индивидуального подхода к контролю процесса записи в файл. Важно учитывать особенности приложения и найти подходящий метод, который обеспечит надежность и последовательность записи данных в файл.
Мониторинг файлового обмена очень сложно контролировать. Обеспечить его прозрачность — непростая задача, потому что файловый обмен может осуществляться через различные каналы и протоколы, в том числе через локальные сети, интернет, сообщения электронной почты, облачные сервисы и т.д. Кроме того, файлы могут быть зашифрованы или упакованы в архивы, что усложняет их обнаружение и контроль. Также необходимо учитывать возможные нарушения конфиденциальности и безопасности при мониторинге файлового обмена, что требует применения соответствующих мер защиты и обеспечения доступа только авторизованным лицам.
Плюсы у файлового обмена тоже есть: прежде всего, скорость и простота. Если нужно быстро настроить обмен данными, этот метод — то, что доктор прописал. При использовании файлового обмена не нужно тратить время на настройку сложных систем передачи данных и обучение пользователей. Помимо этого, файловый обмен не требует дополнительных инвестиций в оборудование или программное обеспечение. Еще один плюс — высокая надежность передачи: файлы сохраняются на диске, а значит не исчезнут при перебоях с интернет-соединением. Если вас интересует быстрый и простой способ обмена файлами, то файловый обмен — отличный выбор.
Способ 2. HTTP-сервисы (REST/SOAP)
Один из самых популярных методов интеграции. С помощью HTTP-сервисов в прикладном решении создается дополнительный прикладной интерфейс, доступ к которому из внешних систем осуществляется через HTTP-запросы. В данном случае, и Java-разработчик будет благодарен, что у него есть «ручка, за которую можно дернуть» (извините за сленг). Или, наоборот, прикладное приложение будет вызывать эндпоинт Java-приложения.
На первый взгляд кажется, что это идеальный способ, но нужно учитывать один момент. Приложения на базе 1С, как правило, не всегда работают 24/7, да и плановые обслуживания никто не отменял. К тому же, для поднятия веб-сервисов на 1С потребуется публикация на веб-сервере. Это, конечно, неплохо, но могут возникнуть некоторые неудобства.
Самый большой минус состоит в том, что приходится вмешиваться в стандартные конфигурации и добавлять собственные эндпоинты, и при обновлении конфигураций системы 1С приходится уделять им внимание.
Этот метод подходит для компаний, где 1С всегда стабильна, нет проблем с производительностью и она доступна 99.9% времени.
Вопросы безопасности я оставляю за рамками статьи, поскольку это отдельная тема, в которую просто надо погрузиться, если вы решили выбрать этот метод взаимодействия между приложениями.
Способ 3. Внешние источники данных
Здесь имеется в виду прямое подключение к базе данных. Такой метод взаимодействия возможен только в одном случае — когда 1С-приложение записывает или берет/пишет данные из/в базу данных. Обратная история, когда Java-приложение будет писать в базу данных 1С, просто утопична. Структура БД 1С:Предприятие закрыта и ее изменения непредсказуемы в силу обновлений платформы и/или конфигурации 1С.
Этот метод применим для стабильных систем, где происходит или совсем отсутствует изменение структуры базы данных Java-приложений.
Моя рекомендация — никогда так не делайте. При прямом подключении к базе данных 1С, Java-приложение может косвенно повлиять на работу 1С и нарушить целостность данных, что приведет к сбоям и ошибкам. Кроме того, при обновлении платформы 1С-приложения, структура базы данных может измениться, что повлечет за собой несовместимость с Java-приложением. Использование API платформы 1С, таких как Web-сервисы, более безопасно и гарантирует корректную работу ИС в целом.
А теперь я расскажу вам о четвертом способе, который мы предпочитаем использовать для решения задач клиентов.
Почему мы пошли по другому пути?
Способ 4. Обмен с с использованием брокеров сообщений
Мы пришли именно к такому методу, поскольку он покрывает все требования качественной интеграции в надежности, скорости обмена, различиям между платформами и расширяемости. Ниже раскрою его подробно, но сначала поделюсь предысторией, как мы пришли к такому решению.
Как правило, в любых компаниях используется множество различных систем — CRM, ERP, HR, финансовые и т.д. — каждая из которых решает узкую задачу. К примеру, в одной компании для поддержки клиентов могут использовать 1С:CRM, в другой — SalesForce, а в третьей — самописное Java-приложение (как наш продукт Maketalents).
Каждая из этих систем имеет свои API, через которые можно осуществлять взаимодействие с ней. Но иногда возникают такие ситуации, когда нужно «сыграть» между двумя и более системами, например:
получить данные из одной системы и передать их в другую;
оповестить систему о событии, которое произошло в другой системе;
отправить запрос во все системы, чтобы получить консолидированную информацию;
передать конфиденциальную информацию между системами и сохранить ее целостность.
Без брокера сообщений между системами реализация этих сценариев достигается путём ручного (возможно, долгого и трудоёмкого) программирования.
Что такое брокер сообщений?
Брокер сообщений — это приложение, которое может получать, обрабатывать и направлять сообщения между различными приложениями.
Разные системы могут быть написаны на разных языках программирования, использовать разные структуры данных для хранения информации, иметь различную специфику отправки и приема сообщений. Поэтому использование брокера сообщений позволяет быстро, надежно и с минимальным программированием обеспечить передачу данных между различными системами.
Примеры брокеров сообщений
Существует множество брокеров сообщений, приведу некоторые из них:
RabbitMQ, Apache Kafka, Apache ActiveMQ — Open Source, наиболее распространенный в сообществе;
Amazon Simple Queue Service (SQS) — сервис от Amazon, который позволяет посылать сообщения через готовые AWS-сервисы;
Microsoft Azure Service Bus — сервис сообщений на платформе Azure;
Google Cloud Pub/Sub — брокер сообщений от Google Cloud.
Каждый из них имеет свои преимущества и недостатки, невозможно выделить один универсальный брокер для всех случаев использования.
Пример использования брокера ActiveMQ
А теперь расскажу о нашем опыте. Мы общаемся с одной системой, которая работает на Java, и другой системой, которая использует свой API, поэтому для обеих систем создаём соответствующие клиенты. Один клиент будет слать сообщения в АctiveMQ, другой — получать.
Объекты между клиентами обмениваются по протоколу AMQP. В протоколе используется понятие «vhost», поэтому для каждой двусторонней интеграции между несколькими очередями создаем отдельный виртуальный хост в АctiveMQ.
АctiveMQ обеспечивает надежность в доставке сообщений с помощью подтверждений. Это означает, что мы можем быть уверены в том, что сообщение не будет потеряно или отправлено неверно. Если отправитель сообщает о том, что сообщение было отправлено, то мы можем быть уверены, что оно находится в очереди.
В качестве приложения-поставщика сообщений 1C можно использовать любое приложение, способное работать с протоколом AMQP.
Брокер сообщений — это действительно удобный и расширяемый метод интеграции разнообразных приложений, поэтому его применение оправдано. Однако не забывайте, что каждое использование брокера сообщений в проекте требует дополнительных затрат на разработку, тестирование и настройку.
Также обращу внимание на минусы, которые стоит учесть:
Сложность настройки. Настройка и управление брокерами сообщений может быть непростым процессом, который требует специализированных знаний и опыта.
Расходы на оборудование и поддержку. Использование брокеров сообщений может потребовать дополнительных затрат на оборудование и поддержку, включая аппаратное и программное обеспечение, а также нести дополнительные расходы на техническую поддержку и обслуживание.
Риски безопасности. Брокеров сообщений могут создавать риски безопасности данных, особенно если они используются для обмена конфиденциальной информацией. Для минимизации этих рисков требуется усиление мер безопасности — шифрование данных и контроль доступа.
Зависимость от поставщика услуг. Использование брокеров сообщений создает зависимость от поставщика услуг, который может повлиять на производительность и доступность обмена сообщениями.
Ограничения масштабируемости. Некоторые брокеры сообщений могут иметь ограничения масштабируемости, что ограничивает возможность расширения системы в будущем.
Резюме
В этой статье мы рассмотрели несколько методов интеграции, каждый из которых имеет свои преимущества, недостатки и может применяться в зависимости от задач и требований конкретного проекта.
Методы обмена с использованием брокера сообщений могут быть полезными для любых систем, которые требуют обмена данными между компонентами или сервисами. В частности, это может помочь в решении следующих задач:
Распределенные системы: когда компоненты приложения работают на разных серверах, брокер сообщений позволяет управлять направлением и хранением информации между этими компонентами.
Обработка сообщений в реальном времени: брокер сообщений может обеспечить быструю, надежную и масштабируемую обработку сообщений в реальном времени.
Интеграция различных систем: с помощью брокера сообщений можно интегрировать различные системы, даже если они работают на разных языках программирования или используют различные протоколы.
Оптимизация производительности: использование брокера сообщений может снизить уровень нагрузки на сеть и сервера, что позволит повысить производительность и быстродействие системы.
Чтобы получить возможность экспериментировать, вы можете изучить небольшое приложение на 1С в качестве внешней обработки, а также приложение на Java, которое доступно по ссылке для обмена информацией через ActiveMQ.
Спасибо за внимание!
Полезные материалы для разработчиков мы также публикуем в наших соцсетях – ВК и Telegram.
