В этой статье попробуем определиться с критериями, влияющими на выбор интеграционного решения. Опишем возможные варианты интеграций, разберем плюсы и минусы.
Статья ориентирована на:
Таким цветом выделены примеры, поясняющие ранее описанные утверждения.
У крупного заказчика обычно множество информационных систем. Каждая система хорошо решает свои специфические задачи. Попытки объединить информационные системы в многофункциональные решения типа ERP привносят свои сложности. Появляются зависимости там, где их не должно быть.
Например, расчет зарплаты в ERP-системе возможен, но при этом расчет зарплаты жестко регулируется законодательством и блок расчета подлежит регулярному обновлению от вендора. Другие блоки ERP-системы могут быть не так зависимы от законодательства и при этом значительно изменены под потребности конкретного бизнеса. Такую систему сложно обновлять. Поиск решения для такой задачи приводит заказчика к выделению блока управления зарплатой и кадрами в отдельную систему на 1С:ЗУП, а ERP-система решает другие задачи.
Другая ситуация, в которой монолитное решение оказывается вынужденно разделено, — это эксплуатация крупных систем, территориально разделенных по стране.
В таком случае пользователи из Приморья вынуждены работать, например, с базой из Москвы, что вызывает определенные задержки. А само наличие дальневосточных пользователей создает проблемы московской базе: становится сложно выбрать время (когда в базе никого нет) для выполнения регламентных работы СУБД и обновления конфигурации.
Некоторые программы в принципе отделены друг от друга на техническом уровне.
К примеру, мобильное приложение на телефоне курьера никак не может быть на связи с общей базой данных. А витрина веб-сайта не может быть технически реализована на платформе 1С, как и, например, база данных IP-телефонии.
Принимаем как данность: у крупного заказчика множество информационных систем. При этом информационные системы хоть и разделены, но работают частично с общими данными.
В ERP-системе для сотрудника рассчитывается премия, в ЗУП — отпускные, а общие данные по расчетам зарплаты являются частью бухгалтерского учета и отражаются 1С:БП. На веб-сайте клиент делает заказ, менеджер в CRM-системе этот заказ подтверждает, проводит работу с клиентом, далее заказ отдаётся ERP-системе для производства и продажи, а оттуда выгружается в базу службы доставки.
Программы разные, но данные в них частично пересекаются. Эти данные желательно передавать между программами не вручную. Во-первых, вручную это долго и ненадежно, во-вторых, неизбежны ошибки ручного ввода.
Интеграция — это всегда взаимодействие двух систем. Даже если этих систем множество и все они как-то взаимосвязаны, то каждая связь существует сама по себе и у нее только два конца.
Интеграции бывают односторонние и двусторонние. Двусторонняя интеграция может быть представлена как две односторонние. Таким образом, любая сколь угодно сложная схема миграции данных сводится к набору односторонних связей «Источник→Приемник».
«Источником» назовем систему, которая изначально содержит нужные данные (неважно были они введены туда вручную или получены в результате другого процесса интеграции).
«Приемником» назовем систему, которая будет получать данные по процессу интеграции.
«Каналом связи» (или «Транспортом») назовём способ передачи данных между Источником и Приемником.
Важное наблюдение!
Из практики разработки множества интеграций сделано простое, но важное наблюдение. Разработчики и менеджеры очень по-разному оценивают сложность процесса интеграции.
Разработчик понимает, что в схеме интеграции самое незначительное звено — это Канал обмена. За редкими исключениями одну и ту же интеграцию можно запустить на выбор по различным каналам, организованным по-разному на техническом уровне. За редким исключением Каналы обмена не являются узким местом в интеграции.
Менеджеры — от заказчика до руководителя разработчика — склонны большое значение придавать именно Каналам. Хотя по факту работа с каналом может занимать 1% от проекта интеграции, вся интеграция будет названа в его честь. Возможно, причина в понятных названиях, которые удобно давать: у нас интеграция через «RabbitMQ!», а у нас через «Apache AirFlow».
Разработчик знает, что самое сложное в процессе интеграции — это договориться между людьми, отвечающими за две соединяемые системы. Этот процесс может тянуться очень долго, требовать больших нервов и не факт, что завершится успешно. Прежде чем писать код, нужно понять: откуда и какие данные брать, кто в какой последовательности их использует, кто имеет право на изменения, на добавление нового и т.д.
Самая долгая техническая часть, где можно написать очень много кода — это описание процесса преобразования данных Источника в структуру понятную Приемнику. Тут всё зависит от задачи.
Передать курс валюты с веб-сайта в 1С базу несложно, а передать результаты работы производственного холдинга в базу бухучета может стать задачей на человеко-месяцы, особенно при несовпадении управленческой и официальной структур предприятия.
Процесс обмена данными разбивается на следующие этапы:
Этапы 1, 2, 3 обычно реализованы в Источнике, этап 4 в Канале, этапы 5-6-7 в Приемнике. Но возможны исключения, в тех случаях, когда Источник или Приемник не способны самостоятельно выполнять программный код или эта задача затруднена. Тогда другие участники цепочки могут взять на себя эту функцию.
Например, умный Канал обмена может сам периодически заходить в базу Источника, выбирать там данные и раскладывать в таблицы базы Приемника. Или, например, Источник данных может связываться с Приемником напрямую, используя синхронный канал (RPC, COM и т.д.), и производить манипуляции в Приемнике, записывая свои данные. Но и Приёмник может сходить в Источник полностью самостоятельно, прочитать данные и записать к себе.
Все такие прямые нестандартные обмены должны быть вынужденной мерой, а не предпочитаемым архитектурным решением. И для этого есть причины.К примеру, 1С Платформа имеет десятки механизмов интеграции: от самых «прямых» до полноценных. Имея столь большой выбор механизма интеграции, следует склоняться к максимально полному, даже если он кажется сложнее технически или менее производительным.
Причины выбрать более полный вариант обмена в сравнении с прямым:
намного проще тестировать и искать ошибки. Когда есть все этапы, можно любой из них эмулировать программно. Можно на тестовый стенд передать реальные данные и обработать. Можно подсмотреть в процесс передачи данных на узловых точках и определить виновника проблемы;
возможно переиспользование кода между разными интеграциями. Например, разные системы Приемники нуждаются в одинаковых данных из нашего Источника. Используя полную модель интеграции, выгрузка данных из Источника возможна по одним и тем же правилам для различных Приемников;
возможна быстрая замена части механизма интеграции на похожий. Например, был обмен через файлы по сети, и вдруг общая локальная сеть стала недоступна одному из участников (например, по соображениям безопасности). Меняем канал обмена на электронную почту или FTP. Незначительные изменения в Источнике и Приемнике. А если бы у нас, например, Источник писал свои данные прямым доступом в базу Приемника, то пришлось бы делать обмен с нуля;
облегчается встраивание мониторинга и оповещений о проблемах обмена. Полноценный обмен с множеством последовательно выполняемых этапов и преобразований дает множество точек для наблюдения и позволяет диагностировать проблемы более точно;
возможность организовать хранение очереди сообщений для расследования проблем;
унификация решений позволяет видеть их все в каком-то общем списке, в то время как «простые» обмены зачастую написаны в неожиданных местах и выпадают из поля зрения разработчиков.
Прямые, неполные, нестандартные интеграции следует выбирать при отсутствии других возможностей.
В мире 1С проблема интеграции между базами 1С существует давно, для ее успешного решения разработаны стандартные подходы.
В 1С исторически выделяют два стандартных типа интеграции — это РИБ и «Конвертация данных». Есть также длинный список менее стандартных способов интеграции как в типовых решениях, так и в виде готовых разработок доступных на разных сайтах.
Распределенная Информационная База — на самом деле частный случай обычной Конвертации Данных, но его в типовых конфигурациях предложили и обособили очень давно (более 20 лет назад, во времена 7.7). Сейчас это устоявшийся термин, который, впрочем, не всегда употребляют правильно, называя РИБом то, что РИБом не является.
Суть РИБ в том, что есть какой-то филиал и все, что в нем сделано, будет передано в центральный офис. Все, что будет сделано в офисе, будет передано во все филиалы. Но вот данные из одного филиала не попадают в другой при стандартных настройках РИБ. Можно вмешаться в процесс и построить более сложные схемы интеграции, чем «звезда», тогда это будет уже не совсем РИБ.
Потребность в РИБ возникает в организации, если она территориально разделена, и требуется обеспечить автономность работы отдельных подразделений. В редких случаях РИБ используют, чтобы снизить нагрузку на большую базу с тысячами одновременных пользователей.
Обмен по РИБ проще обычного в настройке, так как конфигурации в базах данных идентичны. Нет необходимости описывать сложные правила преобразования или поиска данных.
В распределенных базах один узел обязательно является главным, именно в нем возможно изменение конфигурации, которые передаются в дочерние узлы. Это уникальная функциональность РИБ, в других стандартных способах не доступная. Есть возможность быстрого создания нового дочернего узла из копии другого дочернего узла или из главного. Таким образом, настроенный обмен по РИБ может в исключительном случае быть использован как источник восстановления данных при их утере. Конечно, РИБ не является заменой резервному копированию, которое должно быть реализовано на другом техническом уровне проще и надежнее.
Исторически первой стандартной системой построения интеграции между 1С-системами стала конфигурация Конвертация Данных 2 (существовавшие ранее решения не были настолько распространены). КД2 была взята на поддержку в фирму «1С» и внедрена во многие конфигурации, которые сейчас считаются устаревшими.
Современной заменой КД2 является конфигурация Конвертация Данных 3 (КД3), которая поддерживается современными конфигурациями на основе БСП. Интеграция между старой и новой конфигурацией 1С возможна как по КД2, так и по КД3. В основном для таких интеграций используется КД2.
КД2 представляет собой некий комплекс. В зависимости от точки зрения в него можно включать или не включать некоторые компоненты. Опишем процесс интеграции под управлением КД2 целиком и отметим, какие компоненты считаем частями КД2, а какие принадлежащими к другим системам. Далее в этом тексте терминами «КД 2» и «КД3» будем обозначать именно комплекты конфигурации, обработок, подходов, а не базу данных конвертации. Вероятно, такое именование не совсем методологически корректно и является, скорее, народной терминологией, чем официальной.
У нас есть процесс Источник-Канал-Приемник и семь этапов обмена данными (список выше). Где в этой схеме КД2?
Конвертация в этой схеме используется дважды. Основное использование происходит во время настройки процесса интеграции. И некоторая небольшая часть работает уже непосредственно при передаче данных.
Настройка обмена начинается с того, что на базе Источника и на базе Приемника запускаются специальные внешние обработки из состава КД2, они выгружают структуру метаданных Источника и Приемника в виде больших XML-файлов.
Затем открывается отдельная база данных с конфигурацией КД2, в нее загружаются метаданные, которые представляются в виде наборов взаимосвязанных справочников. После чего в графическом виде производится сопоставление данных между Источником и Приемником.
КД2 позволяет описывать простые взаимосвязи быстро, в том числе автоматически. Более сложные сопоставления выполняются при помощи кликов мышкой и выбора из готовых вариантов, а самые сложные можно описать кодом 1С.
Таким образом создается взаимосвязь между метаданными двух конфигураций. Эта взаимосвязь затем должна быть выгружена в виде XML-файла правил конвертации данных.
Верно и обратное: имея метаданные двух конфигураций 1С и правила конвертации в виде XML, мы можем всё это загрузить в чистую базу Конвертации и продолжить настройку правил конвертации, получив в результате усовершенствованную версию.
Итогом работы КД2 является один файл правил конвертации.
Также КД2 может разрабатывать правила регистрации объектов, на практике такое применяется редко, оставляя этот функционал на разработчиков конфигурации Источника.
Полученные правила конвертации будут использоваться каждый раз при выгрузке данных из Источника, и некоторая их часть будет использована при загрузке в Приемник.
В самом простом случае в качестве Канала обмена используется файл на диске.
В базе Источнике запускается внешняя обработка «Обмен данными в формате XML» из состава КД2. В эту обработку подгружаются правила конвертации, ранее созданные при помощи КД2 . Правила определяют логику обработки по выбору данных из базы Источника, формированию файла обмена и записи файла в формате XML на диск. В обработке указывается путь, по которому будет сформирован файл обмена.
В файл обмена также будет записана часть правил конвертации, которая относится к обработке и загрузке данных на стороне Приемника. То есть файл обмена содержит не только данные, но и настройки и даже программный код на языке 1С. Поэтому на стороне Приемника нам не понадобятся правила конвертации. И по этой же причине обмен по КД2 в общем случае возможен только между 1С-системами.
На стороне Приемника запускается та же обработка обмена, но теперь выбирается только путь к файлу обмена. Обработка в процессе загрузки файла считывает настройки и данные из файла, выполняет фрагменты кода, описывающие логику записи данных в Приемнике.Обработка КД2 формирует файл обмена в XML-формате, предполагается обмен через общую папку. Но небольшое изменение в обработках обмена позволяет выбрать другой канал обмена, практически любой, кроме некоторых «прямых» способов.
В состав устаревших типовых конфигураций входят обработки обмена, которые являются вариантами внешней обработки «Обмен данными в формате XML». Они незначительно изменены, например, имеют мастер настройки канала обмена и используют встроенные в конфигурацию правила конвертации данных. Имена файлов обмена там вычисляются автоматически, обычно по префиксам нумерации в базах. При этом есть возможность взять из типовой конфигурации сохраненные внутри правила конвертации, загрузить в базу КД2, исправить и вставить обратно.
Итак, еще раз последовательность этапов при обмене данными и участие компонентов КД2 в процессе:
Упаковка данных в Источнике для передачи в Канал (Сериализация): используется обработка «Выгрузка данных в формате XML» из состава КД2, данные преобразуются в XML- файл согласно правилам конвертации данных.
Передача данных из Источника в Канал: в качестве Канала обычно файл в общей папке, который создаётся обработкой «Выгрузка данных в формате XML» из состава КД2.
Получение данных из Канала в Приемник: загрузка данных производится обработкой «Загрузка данных в формате XML» из состава КД2.
Запись данных в Приемнике: обработка «Загрузка данных в формате XML» записывает данные в Приемнике и дополнительно выполняет код на языке 1С.
Предположим, у нас есть три базы, каждая из которых соединена двусторонним обменом с другими базами. Итого шесть обменов. В реалиях КД2 это шесть правил конвертации данных.
КД 2 описывает превращение данных Источника в Приемник, а КД3 описывает превращение данных Источника в универсальный формат и обратное превращение из универсального формата в данные базы.
Для предыдущего примера понадобится всего три правила конвертации.
Другой пример.
Нужно только выгружать данные из одного Источника в один Приемник. Для КД2 это один файл правил конвертации. Для КД 3 это два файла правил. Правила выгрузки из Источника в универсальный формат и правила загрузки из универсального формата в Приемник.
КД3 в файл обмена помещает только данные обмена.
КД2 для загрузки данных требует только файл обмена.
КД3 для загрузки данных требует файл обмена, правила загрузки данных и описание формата обмена.
В КД2 для разработки правил обмена программист должен знать обе конфигурации.
В КД3 правила обмена можно разрабатывать, зная только одну из конфигураций и договорившись об универсальном формате с программистом, который будет разрабатывать вторую часть правил.
КД2 предназначена для связи между 1С-системами.
КД3 может быть использована для связи с системами не на 1С, так как файл обмена содержит только данные, он может быть прочитан сторонней программой, или сформирован сторонней программой. Но сама настройка обмена в базе КД3 выполняется для 1С систем и похожа на такую у КД2, поэтому большого распространения настройка обмена через КД3 для «не 1С» систем не получила.
КД2 для непосредственного выполнения обмена требует только обработки, которые могут быть внешними. В случае типовых решений это будут обработки, встроенные в конфигурацию, регламентное задание и макет с правилами обмена. В любом случае объектов немного, и к КД2-обмену можно быстро подключить самописную конфигурацию, ранее такого обмена не имевшую.
КД3 опирается на подсистему БСП (Библиотека стандартных подсистем) «Обмен данными» и без нее не может существовать. Эта подсистема содержит ряд модулей и метаданных и сама по себе опирается на другие части БСП (стандартные подсистемы, пользователи …). КД3 сложнее внедрить в конфигурацию, ранее не имевшую БСП, и очень сложно запустить на платформе 1С 8.2. Кроме того, в современных типовых конфигурациях существует непубличная БСД (Библиотека синхронизации данных), которая является надстройкой над БСП «Обмен данными» и предлагает дополнительный функционал, например, выбор канала обмена.
Для многих современных конфигураций на 1С написаны правила обмена на КД3, а типовой механизм настроек обмена дополнен помощником настройки. В качестве промежуточного формата обмена (обязательного в КД3) используется иногда формат Enterprise Data 2, описание которого есть в общем доступе. В некоторых случаях используются измененные версии этого формата с данными специфичными для подключающихся конфигураций.
Вообще для КД3 преимуществом как раз и называют выгрузку в универсальный промежуточный формат. Можно подключить много разных конфигураций к централизованному обмену: и внешние системы помимо 1С можно подключить, и формат выбран общераспространенный, а не специфичный для 1С.
Это все так, но с оговорками. При настройке обмена между нестандартными конфигурациями не хватает стандартного формата. Как правило, полностью настроенный сложный обмен приводит к сильным изменениям формата, либо к созданию своего формата с нуля.
Для сторонних решений «не-1С», не существует обработок выгрузки метаданных для сопоставления в КД3. Теряется простота настроек. Технически построить сложный обмен по правилам КД3 между 1С и «не-1С» возможно, но не так просто, как между 1С-системами.
Прямая запись в БД. Вероятно, наихудшее возможное решение применительно к 1С. Не проверяются никакие обработчики данных, не проверяются права доступа, имена таблиц могут быть изменены (выгрузка-загрузка DT). Прямое нарушение всех архитектурных стандартов. Риск нарушения логической целостности базы. Плюсов у такой интеграции практически нет, кроме скорости записи данных, которая обычно не является узким местом.
Прямое чтение из БД. Не совсем то же самое, что прямая запись, но тоже очень плохо. Здесь нет рисков сломать базу, но есть риски читать что-то не то, читать что нельзя, потерять интеграцию при смене сервера СУБД.
COM и OLE-соединения к базе напрямую. Поддерживается только в Windows. Определенные сложности возникают с разработкой сложных обменов из-за ограничения типов передаваемых данных.
Web-сервисы и WS-ссылки с XDTO. Исторически довольно старый механизм обмена через сеть. База 1С публикует WEB-сервисы и общее описание всех своих сервисов. Сторонняя программа, которой может быть так же 1С по WS-ссылке, формирует SOAP-запрос на вызов определенного сервиса, передает параметры и ожидает результата. Для описания параметров и результатов в 1С существует специальный механизм XDTO-пакетов, позволяющий составить XSD-схему и механизм фабрики XDTO, которая может создавать из данных объектов 1С объекты XDTO, записываемые в XML. Это все, своего рода, упрощенная реализация КД3 на механизмах платформы. Подобные интеграции встречаются редко, так как между 1С предпочтительнее использовать КД2–КД3, а сторонние системы обычно выбирают HTTP – REST-сервисы и не имеют хороших библиотек для описания SOAP-запросов. Программисты такое не любят.
HTTP-Сервисы. Появились в платформе уже довольно давно, но их все еще считают более новыми в сравнении с WEB-сервисами. Платформа позволяет публиковать сервисы как набор точек интеграции для REST-интерфейса. Что именно будет передано и получено по этим сервисам — вопрос бизнес-логики. Начиная от архитектурно некрасивых правок в данных напрямую без логирования и с неверным использованием REST и до обмена по стандарту КД3. HTTP-Сервис — это Канал, он не определяет всю логику работы обмена. Сюда же отнесем HTTP-соединения как способ из 1Собратиться к внешнему HTTP-сервису. HTTP- и WEB-сервисы работают по одному протоколу. Что из них выбрать для соединения двух баз 1С? Принципиальное различие в способе проверки структуры данных. WEB-сервис заставляет того, кто к нему обращается, предварительно проверять данные. HTTP-сервис принимает практически что угодно. Например, программист внес незначительные изменения в структуру базы данных, которая обращается к HTTP-сервису. В таком случае обмен данными, скорее всего, продолжит работать, но есть небольшая вероятность, что передаваемые данные перестанут нести практический смысл. В случае обращения к WEB-сервису любое изменение структуры — это сразу ошибка обмена, даже если просто добавлен новый незначительный для обмена реквизит. Для сложных обменов с большим числом различных объектов рекомендуем использовать WEB-сервисы (из этих двух вариантов), лучше встречать больше ошибок обмена, чем не встречать ошибок, но иметь незамеченные. Предположительно в 2025 году в Платформе 1С к паре HTTP и WEB добавится третий, совсем новый участник. Протокол WebSocket, который позволит многократно ускорить обмен небольшими сообщениями.
Выгрузки в файлы без использования правил конвертации. Как правило, такие обмены создаются начинающими программистами. В них перемешана логика сбора данных, логика формирования файла обмена и записи в него. Нередко у такого обмена может быть формат txt или csv без внутренней структуры. Архитектурно очень плохие обмены: сложно поддерживать, легко потерять, много ошибок. Вынужденно существуют нормальные обмены в таком формате, когда на другой стороне не 1С, а, например, торговое оборудование или маркетплейс с четко утвержденными формами входящих документов в формате Excel.
Обмены через брокеры сообщений (Rabbit, Kafka). Это только технология обмена, определяющая Канал обмена, но не бизнес-логику происходящего. Упрощенно можно сравнить с обменом через почту. Данные технологии обеспечивают передачу очень большого количества сообщений в секунду, фактически неограниченное. Они практически всегда асинхронные. То есть Источник отправляет сообщение и не ожидает ответа от Приемника в рамках того же соединения (как это происходит, например, в HTTP-сервисах). Приемник может включиться в любое время позже и начать вычитывать свою входящую очередь с доступной ему скоростью. Ограничением скорости в таких обменах служит обычно скорость, с которой Приемник способен записывать данные, реже скорость отдачи из Источника и никогда пропускная способность Канала.
Вариант архитектуры интеграции между 1С и сторонней программой по HTTP в формате JSON без использования правил конвертации.
Например, есть задача. Существует некоторая CRM система, пользователи которой ведут список лидов до оформления Сделки. Оформленная Сделка должна передаваться в базу 1С для обработки, где по Сделке формируется Заказ покупателя, затем Продажа, поступление денег. Статус заказа должен передаваться в CRM-систему по мере изменений в 1С. При этом заказ считается закрытым, когда в CRM- системе ему присвоен конечный статус (вручную менеджером). Именно эта информация нас интересует в 1С.
Допустим, CRM-система имеет API для присвоения статусов Сделок и чтения статусов сделок доступный по HTTP, умеет обращаться по HTTP к сторонним системам.
Решением задачи будет следующая архитектура:
На стороне 1С создаем регистры сведений «Очередь входящих сообщений из CRM» и «Очередь исходящих сообщений для CRM», аналогичные таблицы данных должны быть созданы на стороне CRM.
Когда в CRM сделка переходит из статуса «Новый» в «Согласовано» или из любого ненового статуса в любой другой, то на стороне CRM происходит запись сообщения для 1С в очередь отправки.
Протокол HTTP синхронный. Он требует, во-первых, чтобы сервер был доступен во время обращения, во-вторых, чтобы он успел выдать ответ до истечения таймаута (обычно 60 секунд, можно настроить, но лучше не трогать).
Чтобы данные по такому протоколу гарантированно уходили, необходимо организовать очередь отправки данных в системе отправителе. Тогда изменения, вносимые пользователем, гарантированно попадают в очередь, ведь очередь не обрабатывается сразу, а только сохраняет сообщение.
Другой фоновый процесс в CRM должен периодически обрабатывать очередь, искать там все сообщения со статусом «К отправке» и пытаться их отправить. Сообщения, которые удалось отправить, можно удалять либо применять к ним статус «Отправлено» и удалять позже, спустя несколько дней или недель. Такая очередь ранее отправленных сообщений не создаст большой нагрузки на базу, но предоставит возможность отладки, поиска ошибки, повторной отправки. Важно только не копить сообщения бесконечно, механизм чистки очереди должен существовать.
На стороне 1С HTTP-сервис, к которому обратилась CRM, производит простую запись сообщения в регистр сведений. Без попытки разбора этого сообщения, только запись в регистр и ответ 200, если эта запись удалась. При записи сообщение в очереди получает статус «получено».
Затем другой фоновый процесс на стороне 1С разбирает очередь входящих сообщений со статусом «Получено» и их, создавая Заказы. Можно также хранить некоторую глубину пришедших и обработанных сообщений, не удаляя сообщения из очереди сразу, а выставляя статус «Обработано» сообщению, удаляя обработанные сообщения спустя несколько дней/недель. Обработка создания заказа и изменение статуса в очереди сообщений должны происходить в одной транзакции.
Для сообщений, которые не удалось обработать, у которых в транзакции произошла ошибка, можно устанавливать статус «Ошибка». Входящие сообщения со статусом «Ошибка» можно пытаться обработать при следующем проходе регламентного задания, а можно отдавать такие ошибки в систему мониторинга, уведомляя программистов о возникшей проблеме в момент ее возникновения, а не спустя несколько дней, когда менеджер начинает искать свой заказ.
В обратную сторону обмен выглядит так же: сначала синхронно с действиями пользователя формируются сообщения для отправки и помещаются в очередь. Затем отдельно от пользователя эта очередь обрабатывается для отправки; на стороне приемника данные записываются во входящую очередь «как есть», затем асинхронно входящая очередь превращается в изменения бизнес-сущностей.
Собственное ESB-решение, предлагаемое фирмой «1С», находится в процессе активной разработки, регулярно появляются новые возможности. Входит в реестр отечественного ПО.
Для программирования бизнес-логики Шины используется собственная графическая IDE, запускаемая в браузере, там же может быть написан код на языке 1С:Элемент, расширяющий функционал Шины по обработке и маршрутизации данных. К примеру, можно получить входящее сообщение, разобрать его и в зависимости от содержимого отправить одному или другому получателю. Или, например, получить входящее сообщение с файлом, описывающим массив документов в формате json, и преобразовать его в несколько сообщений с отдельными документами в формате XML.
Шина умеет обращаться к различным источникам данных, например, выполнять HTTP-запросы, читать файлы из папок, с FTP, читать данные различных СУБД при наличии для них JDBC драйвера (очень большой список). Шина может получать данные из многих разных источников, в том числе от другой 1С:Шины.
Для интеграции 1С:Шины с Платформой 1С, начиная с версии 8.3.16 появился механизм сервисов интеграции, который поддерживает очереди обмена в базе 1С и выполняет обмен этих очередей с Шиной. Фактически обмен происходит в формате AMQP и может быть использован для обмена со сторонними системами в этом формате. Для более старых версий платформы возможна интеграция по HTTP или любым способом доступным платформе и Шине.
Последние обновления многих типовых конфигураций от 1С содержат настройки для обмена по 1С:Шина.
Необходимо выбирать тот механизм интеграции, который наиболее полно обрабатывает все этапы процесса обмена данными и позволяет обособить их. Конкретное решение зависит от перечня связываемых между собой информационных систем:
Если это современные конфигурации 1С на основе БСП, тогда стандартная синхронизация данных по формату КД3 с максимальным использованием готовых обменов данными. Канал обмена вторичен и может быть изменен в любое время в процессе настройки или эксплуатации;
Если это устаревшие конфигурации или решения не на основе БСП. Можно рассмотреть внедрение БСП, когда речь идет о современной платформе 1С и свести ситуацию к варианту 1. Либо воспользоваться возможностями обмена по формату КД2;
Если одна из двух системы не на Платформе 1С. Все зависит от доступных для «не-1С» системы способов интеграции. Система на Платформе 1С, как правило, более гибко настраивается и программируется под ограниченные возможности сторонней системы. Если способов интеграции несколько, то приведу в порядке выбора приоритета: HTTP-сервисы (де-факто стандарт для интеграций с внешними API); WEB-сервисы (редко встречающаяся возможность); Обмен файлами; Прямое чтение базы сторонней системы обращением из 1С; Прямая запись в базу данных 1С (не делайте так никогда).
Для соединения 1С и «не-1С» в качества средства интеграции разумно рассмотреть шины данных. Они возьмут на себя общение с «не-1С» системой по понятным ей протоколам и передадут в 1С «хорошим» способом. Например, 1С:Шина имеет больше возможностей соединения со сторонними системами, чем Платформа 1С, а с самой Платформой 1С соединяется специальным коннектором с поддержкой транзакционной целостности обмена.
Интеграция информационных систем может быть непростой задачей. Специалисты «1С-Премиум» готовы оказать вам поддержку как с архитектурой интеграции, созданием механизма мониторинга и уведомления, так и с созданием интеграции под ключ.