Правильная интеграция «1С» с другими системами

Система хранения в любой из программ «1С» устроена в виде многоуровневой сложной базы данных. В ней прописаны взаимосвязи и взаимозависимость данных, их связи с объектами с высокой степенью абстракции. Однако, по нашему опыту, компании крайне редко используют «1С» в том же виде и в той же конфигурации, что предоставляются пользователю первоначально, «из коробки».

Каждая компания дорабатывает системы под себя, под особенности своих бизнес-процессов, оргструктуры, производимой продукции и т. д.

Как результат - структура данных становится ещё более специфичной и уникальной.

Пока всё это крутится внутри одной системы, проблем не возникает.

Но если нужно интегрировать «1С» с другими системами, специфика хранения информации усложняет эту задачу.

От этого зависит, какая из команд разработки будет создавать и перерабатывать интеграцию и на какую систему ляжет нагрузка.

- в EnterpriseData (основан на XML), а, например, Axapta - тоже в XML, но в «чистом».

Какие именно данные нужно забирать и отправлять?

Как правило, системе-приёмнику не нужно «всё, везде и сразу» - только отдельные поля или записи за определённый период времени.

Нужно определить, что это за поля, отделить их от общего массива данных и направить в соответствующие слоты приёмника.

Если в справочнике цветов в «1С:Розница» ещё не заведено значение «красный», записать такие данные будет невозможно.

Всё это необходимо учесть уже на этапе первоначальной разработки интеграции. «1С» регулярно выпускает релизы и обновляет код своих продуктов.

Та организация данных, под которую вы писали свою интеграцию, после любого из обновлений может стать неактуальной.

Поменяются названия полей, какие-то поля разделятся на два или объединятся. И все интеграции, связанные с «1С», придётся перерабатывать в соответствии с новыми обстоятельствами.

Изменения могут быть и на стороне второй системы, участвующей в обмене данными, - и интеграцию вновь придётся менять.

Первый (и более предпочтительный, как показывает практика) вариант реализации прямых интеграций - работа через универсальный протокол OData (сокр. от англ. open data protocol). У продуктов «1С», в частности «1С:Предприятие» версии 8.3.5 и новее, предустановлена возможность работы через OData - открытый веб-протокол для запроса, добавления, удаления и обновления данных. OData позволяет выполнять операции с ресурсами при помощи HTTP-запросов и получать ответы в форматах XML и JSON.

Это универсальный протокол, которым пользуется не только «1С», но и другие системы.

Поэтому системы в контуре легче «поймут» полученные данные.

Чтобы использовать протокол OData, нужно включить его поддержку в настройках «1С».

После этого система автоматически создаст REST-интерфейс для обмена данными между «1С» и другими системами. И уже к нему можно будет «присоединить» интеграцию и настроить выгрузку и загрузку данных.

Если же система старше версии 8.3.5 (например, 8.2), воспользоваться универсальным протоколом OData не получится.

Придётся писать API и интеграцию для каждой из подключаемых систем.

Практика написания API - стандартное решение для настройки «общения» между двумя системами.

Но тут надо учитывать, что API пишут люди.

Причём люди разные, с разным опытом и разной логикой.

Каждый из них: написан в своей логике; работает по своей логике; в будущем должен дорабатываться… да-да, вновь в собственной логике.

После каждого обновления «1С» вашей команде придётся отдельно дорабатывать каждый из API в соответствии со свежими изменениями и внутренней логикой API. В лучшем случае делать это будет тот же специалист, который разрабатывал API, - ему будет проще воссоздать ход своих мыслей при написании кода. В худшем (с точки зрения временны́х затрат) - абсолютно новый специалист, который практикует иные подходы к написанию API.

Проблему «зоопарка» можно решить введением жёстких стандартов написания API (хотя на практике такое срабатывает далеко не всегда) или искусственным уменьшением количества интеграций.

Пример такого сокращения мы видели в одном из проектов.

Чтобы сократить «зоопарк» в «1С»-источнике (системе, в которую сохраняли данные о товарах поставщиков), разработчики компании реализовали интеграцию по цепочке. «Битрикс» собирал из других систем информацию об остатках, ценах, товарах и т. д. и передавал в «1С»-источник. «1С»-источник передавал все данные о товарах в систему «1С», ответственную за офлайн-розницу.

Из неё часть первоначальной информации поступала в «1С», ответственную за онлайн-витрину. С одной стороны, это уменьшало количество интеграций как таковых. С другой - каждое следующее звено делало контур в целом более уязвимым, давало больше простора для возникновения ошибок и потерь.

Ведь любой сбой в интеграции или в системе-звене приводил к тому, что информация застревала и не доходила до следующих этапов.

ESB нельзя назвать «волшебной таблеткой» для интеграции «1С» с чем угодно. Во-первых, интеграции ещё предстоит правильно спроектировать: разделить домены и потоки информации. Во-вторых, для создания связи между «1С» и ESB придётся разрабатывать отдельный API на каждую сущность или подключать тот же протокол OData.

Чаще всего «1С» с каждой из систем обменивается не одним-двумя, а пятью и даже десятью потоками данных. И реальная схема обмена данными выглядит несколько сложнее, чем простая паутинка.

Мы не предлагаем при интеграциях через ESB «сливать» весь массив данных через один коннектор и один поток.

Более того, крайне не рекомендуем это делать, поскольку так нагрузка на интеграцию возрастает в десятки раз и пропорционально растёт риск сбоев.

Учёт производительности систем В логику ESB можно заложить скорость выгрузки и загрузки данных в конечные системы в зависимости от их производительности и суточной динамики загруженности. Например, если днём ваша CRM может принимать 100 транзакций в минуту, а ночью - 500, ESB учтёт эту логику и не перегрузит ваши системы.

Своевременное обнаружение ошибок Как правило,

В одном из недавних проектов для международной компании из сферы e-commerce и ретейл команда KT.Team настраивала интеграции для нескольких систем «1С»: ERP, OMS, UMP, CMS.

Мы внедрили интеграционную шину и реализовали 13 коннекторов для семи потоков данных: один коннектор принимает заказы из OMS; один коннектор передаёт данные о заказах в ERP; два коннектора обеспечивают обмен статусами заказов между OMS и ERP; один коннектор передаёт данные о заказах в сервис расчёта вознаграждений; два коннектора передают данные о пользователях в сервис расчёта вознаграждений; четыре коннектора для данных о валютах и странах пользователей; два коннектора нужны для фильтрации по складам.

Для каждой сущности настроен отдельный коннектор (или несколько, если этого требует логика).

Это позволяет более контролируемо передавать данные между системами.

Если вы уже изучали вопрос, то, возможно, первым и логичным ответом для вас будет «1С:Шина».

Продукт из того же семейства действительно легко интегрируется с «1С:ERP Управление предприятием»