Способы интеграции 1С и корпоративного хранилища данных

Процесс передачи информации из 1С в корпоративное хранилище данных для интеграторов часто оборачивается головной болью. В целом, информационные системы 1С легко взаимодействуют друг с другом за счет платформенных механизмов и правил. Для интеграции 1С с КХД нужно использовать сторонние способы — их мы и рассмотрим в статье. 

Подготовка к интеграции - определение состава переносимых данных

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

Во-вторых, интеграционный поток между системами-источниками и приемником модифицируется гораздо чаще, по сравнению со случаем обмена информацией между транзакционными системами. Благодаря изменениям запросов бизнеса меняется структура КХД, что влияет на интеграции. Новые разрезы учета в транзакционных системах неминуемо попадают в пространство аналитических систем. 

Частое изменение требований к собираемым данным — главная отличительная черта интеграции с аналитическими хранилищами.

Сам характер запросов к данным при работе с аналитическим хранилищем задает требования изменчивости своей структуры. Сотрудникам компании, решившим спроектировать интеграционные потоки, нужно сначала ответить на ряд вопросов. Ответ на любой из них рождает пласт итерационной аналитической работы, которая предполагает, что для выстраивания стабильного процесса необходимо постоянное взаимодействие аналитика данных с системой-источником:

1. "Действительно ли в системах есть нужные данные?"

2. "Достаточно ли заполнены разрезы учета во всех источниках, чтобы выстроить по ним сквозную аналитику?"

3. "Можно ли доверять полученным данным?" и пр.

Поэтому единый центр получения и трансформации данных — основной инструмент дата-аналитиков при разработке КХД. Это один из аспектов, который помещает системы класса ETL в красный угол решений, участвующих в создании аналитических хранилищ.

Основные способы интеграции 1С и КХД

Каким бы ни был способ переноса данных — правила формирования составов данных должны тиражироваться на большое количество источников. Чтобы упростить процесс сбора данных, важно, чтобы дата-аналитики или дата-инженеры могли менять составы получаемых данных в КХД с минимальным привлечением программистов или без них. 

Рассмотрим самые популярные способы получения данных из 1С. 

Выгрузка через файл

Пожалуй, наиболее распространенный метод интеграции 1С с корпоративным хранилищем данных. 1С-программист пишет обработку выгрузки в файл и настраивает расписание выгрузки в каталог, а далее файлы загружаются в КХД. При таком обмене контуры 1С и КХД остаются разделенными между собой. 

Как правило, за разработку такого решения отвечают две команды специалистов: одна работает с выгрузкой, другая — с загрузкой.

Преимущество этого подхода — в относительной технологической простоте. Она же рождает большое количество недостатков:

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

2. Нельзя выгружать только что обновленные данные. Потому что система не понимает, какие данные успешно загружены (обновлены) в КХД, а какие — нет. 

3. Чтобы хранилище гарантированно имело корректные данные, нужно поддерживать избыточность выгрузки. Это увеличивает нагрузку на контуры и время формирования данных.

4. Несогласованность структуры выгрузки и КХД в случае появления изменений структуры приемника или источника. Эффект, нередко приводящий к остановке процесса обогащения хранилища. Из-за того, что за выгрузку и загрузку отвечают разные команды — это увеличивает время отладки интеграционных процессов. 

5. Необходимость контроля за разработкой и сопровождением выгрузок. Перед созданием группы обработок по выгрузке необходимо утвердить корпоративный шаблон обработки, который будет включать в себя описание программного интерфейса, а также методов и способов формирования структуры данных, добавленных из 1С. Иначе процесс сопровождения обработок под КХД, измененных несколько раз, станет сложнее и дороже. 

6. Нецентрализованная поддержка. Для сбора информации из нескольких источников нужно наладить синхронное обновление обработок выгрузки. И, в случае сбоев, каждый раз отвечать на вопрос: «Актуальная ли обработка сейчас установлена?». Этот процесс требует автоматизации и проработки перед стартом проекта интеграции.

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

Интеграция через OData с помощью REST‐интерфейса

OData — это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды.

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

В числе преимуществ этого решения:

1. 1С не хранит выполняемые обработки в каждом из своих экземпляров — нет необходимости в поддержке их актуальности.

2. Скорость подключения интеграционных потоков выше по сравнению с файловым обменом.

Недостатками такого способа являются:

1. Сложность написания запросов к интерфейсу, который обладает довольно сложной структурой. 

2. Трудности при работе с большими объемами данных. При их передаче веб-сервер может обрезать часть передаваемых сообщений. Для того, чтобы этого не происходило, необходимо предусмотреть механизмы разделения данных на «порции», что усложнит поддержку работы с запросами. 

3. Сложность анализа ошибок. Ошибки, возникающие при получении данных, описываются интерфейсом довольно скупо. На их отладку и исправление уходит значительное время. 

4. Как и в случае с файловым обменом, необходимо поддерживать избыточность выгрузки для согласованности данных 1С и КХД. 

REST-интерфейс явно лучше файлового обмена, ведь его можно использовать для переноса небольших объемов данных с элементами, не требующими написания сложных запросов (если вы готовы перенести часть расчетной логики в КХД).

Подключение к СУБД напрямую

Можно подключить ETL-инструмент не к 1С, а к СУБД, на которой функционирует 1С. Существуют методы и даже коммерческие обработки, которые позволяют писать такие запросы. Преимущество этого решения — в возможности использования стандартных ETL-инструментов для получения данных из SQL. 

Недостатков два:

Интеграция через HTTP‐ и WS‐сервисы

Суть решения — в создании отдельных сервисов для передачи данных, которые встраиваются в конфигурацию источника. Такие сервисы используются как на стороне источников, так и на стороне приемника (или и там, и там). 

Создавая самостоятельные HTTP‐ и WS‐сервисы, специалисты разрабатывают форматы и логику обмена данными с нуля и тратят силы на написание API взаимодействия между источниками и приемником. Но все проблемы указанные в предыдущих способах интеграции 1С с КХД решаются почти на сто процентов. 

Главное преимущество интеграции через HTTP‐ и WS‐сервисы — в возможности гарантированной доставки данных. Недостаток — в необходимости разработки сервисов интеграции (с реализацией логики работы и взаимодействия с учетом кастомизации решения и прицелом на дальнейшее расширение). 

ESB-системы и брокеры сообщений

Корпоративная интеграционная шина данных как класс систем в сервис-ориентированной архитектуре — это основной инструмент гарантированной доставки информации. Применяя ESB-системы и брокеры сообщений (Apache Kafka, RabbitMQ) мы доставляем формируемые сообщения в КХД с высокой скоростью.

С недавнего времени в экосистеме 1С существует специальный продукт «1С:Шина». В соответствии со своим названием он используется для связки систем через сервисную шину данных.

Интеграции для Apache Kafka и RabbitMQ поделены на два типа:

1. Клиент Apache Kafka или RabbitMQ инициализируется через отдельные микросервисы, которые запускают HTTP-сервисы для обмена данными с системой 1С. 

2. Клиент брокера сообщений инициализируется как COM-объект (в котором доступ к данным объекта достигается исключительно с помощью одного или нескольких наборов связанных функций). 

Преимущество обмена через шину или брокеры сообщений — гарантированная и высокоскоростная доставка информации получателям. 

Недостаток этого подхода обнаруживается при наполнении аналитического хранилища. Программистам приходится справляться с трудностями при создании инструментов для работы с потоками данных (настраивать их логику, а также задавать правила регистрации изменений и формирования сообщений). 

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

Кроме того, при использовании брокеров сообщений, которые не поддерживают стандартный обмен с 1С (а это — все брокеры, кроме продукта «1С:Шина»), придется ввести в периметр администрирования ряд микросервисов для наладки взаимодействия на каждом экземпляре 1С.

Как Modus ETL работает с 1С

Modus ETL разрабатывался как продукт, способный ежедневно собирать данные из 800 учреждений со своими экземплярами приложений в консолидированную базу. Потоки интеграции настраивали 1С-аналитики — в тех количествах, которые были необходимы бизнес-пользователям. 

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

Мы объединили источники данных в наборы с общей конфигурацией и одинаковым назначением. Для каждого из наборов устанавливаются свои правила получения данных. В случае с 1С эти правила позволяют аналитикам и программистам в ETL:

• писать запросы для их выполнения на стороне 1С-источника;

• получать результаты СКД-схем в отчетах конфигурации;

• получать изменения на узлах обмена;

• запускать внешние обработки и выполнять произвольный код на стороне источников.

Для получения большого объема данных аналитики могут устанавливать порционную загрузку, разделяя потоки собираемой информации. Порции могут передаваться либо параллельно, либо последовательно, друг за другом. 

Механизм интеграции

При получении данных из 1С выполняется двухсторонний обмен ETL с HTTP-сервисом. 

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

Управление доступом, авторизация и администрирование

При установке адаптера на систему-источник администратор должен определить способы авторизации ETL и базы источника. 

Если мы хотим выдать ETL право собирать все данные — нужно установить роль выполнения запросов в привилегированном режиме. Говоря иначе, необходимо определить доступность данных для ETL на уровне ролей и профилей групп, а также установить роль безопасного получения данных. 

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

Подведем итоги

При выборе способа интеграции 1С с КХД нужно принимать во внимание тот факт, что состав получаемой информации часто меняется. Соответственно, для удовлетворения потребностей бизнеса необходимо оперативно менять и интеграционные потоки. 

Предпочтительные решения для создания интеграции между 1С и корпоративным хранилищем данных — это шины и брокеры сообщений, а также специальные сервисы интеграции с ETL-системами.

Вне зависимости от выбранного способа интеграции 1С с КХД, необходимо создать единый центр управления данными для сбора консолидированной информации из систем-источников. Тогда аналитики данных смогут изменять состав загружаемой информации либо самостоятельно, либо с минимальной помощью программистов. А это, в свою очередь, значительно сократит время разработки интеграционных процессов.