Проблемы интеграции данных различных информационных баз

Проблемы интеграции данных различных информационных баз

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

Целью статьи является попытка понять, с какими проблемами мы столкнемся при использовании модульной системы, в которой разные модули будут находиться в разных информационных базах или при интеграции с существующими учетными системами. В интернете существуют работы  на эту тему, например в  википедии http://ru.wikipedia.org/wiki/Интеграция_данных. Если сравнить данную статью с википедией, то мы рассматриваем интеграцию данных распространением.

Проанализировав свой опыт и материалы, которые удалось найти в интернете, мы разделили проблемы на следующие классы:

• Ссылочная целостность данных;
• Коллизия изменений;
• Корректность данных;
• Последовательность ввода данных;
• Структурное различие схем данных.

Ссылочная целостность данных

Под ссылочной целостностью понимается необходимое качество реляционной базы данных, заключающееся в отсутствии в любом её отношении внешних ключей, ссылающихся на несуществующие кортежи (http://ru.wikipedia.org/wiki/Ссылочная_целостность). Ссылочная целостность поддерживается в базах данных «правильной» логикой, то есть программный код не содержит алгоритмов, приводящих к отсутствию ссылочной целостности и механизмов транзакций.

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

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

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

Выводы: Проблема, по опыту, не самая актуальная. На данный момент решить её на 100% не представляется возможным. Существует возможность снизить проявление за счет частичного решения проблемы (например, платформа уже решила проблему чтения изменений, используя для этого единую транзакцию).

Коллизия изменений

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

Изменение одних и тех же данных в пределах одной информационной базы поддерживается платформой механизмом объектных блокировок (пессимистическая и оптимистическая блокировка, механизм описан здесь http://1cexpo.ru/informacziya/27-blokirovki-dannyx-v-1spredpriyatii-8.html), причем только для ссылочных данных (справочник, документ и т.п.). В различных информационных базах установка такого рода блокировок кажется очень трудоемкой. В результате в двух системах может быть изменен один объект. Какие объекты «подвержены» изменениям можно выявить на этапе внедрения, в основном это объекты, которые изменяют разные отделы. Например, платежные документы загружает Казначейство, а разноску денег по заказам делает менеджер (довольно реальный пример для УТ 11). При этом загрузка платежных документов может выполняться в базу бухгалтерии. Платежный документ может быть загружен в информационную базу несколько раз или в загруженном документе бухгалтером будут произведены изменения, потому что ему там что-то не понравилось. В результате документ меняется в двух информационных базах примерно в одно время. Это может привести к возникновению коллизий изменений и потери каких-либо из них.

Из интуитивных соображений понятно, что чем меньше время, когда в информационных базах находятся разные версии объектов, тем больше вероятность получить коллизию изменений. Тем самым уменьшая время обмена данными можно уменьшить вероятность появления коллизий. Другой возможный путь, редактировать каждый объект, только в одной информационной базе. Например, платежные документы загружаются в БП, далее казначей подтверждает, что все документы корректны (флаг в документе или ещё, какой-либо признак), после чего редактирование данных выполняется только в УТ 11. Последний способ создает неудобство казначею, при необходимости что-либо поменять в документе, после подтверждения, ему необходим доступ в другую информационную базу.

Выводы: Проблема актуальна. Найденные решения либо не решают проблему на 100%, либо неудобны пользователям.

Корректность данных

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

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

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

Выводы: Проблема актуальна. В общем случае решение не найдено.

Последовательность ввода данных

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

Рассмотрим проблему на примере обмена Управление торговлей, ред. 11 (УТ) и Бухгалтерия предприятия (БП).  В конфигурации УТ в платежных документах поле договор может не заполняться, но в документах БП поле обязательно к заполнению. В результате, для заполнения договора в документе сделаны правила обмена, в которых поиск договора выполняется при загрузке по некоторым полям (Контрагент, Организация и т.д.).  При этом в УТ существует возможность ввести договора, при этом синхронизация договоров с договорами бухгалтерии выполняется по уникальным идентификаторам. Предположим, пользователь завел договор с клиентом и оформил приходный кассовый ордер. В ПКО договор отсутствует. Так как последовательность, в которой ПКО и договор попадут в бухгалтерию, нам неизвестна, то существует вероятность, что ПКО попадет раньше. В результате при загрузке ПКО будет создан новый договор, а после добавится договор, заведенный в УТ. Таким образом, можно получить «замусоривание» справочника договоров.

Также последовательность ввода данных может привести к невозможности заполнения полей при загрузке. Например, если в УТ завести склад и, например, поступление на этот склад, а в правилах загрузки в БП написать заполнение подразделения в поступлении написать Склад.Подразделение, то поле подразделение может остаться пустым после обмена. Произойдет это из-за того, что склада может не быть в приемнике на момент загрузки документа.

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

Выводы: Проблема актуальна. Решение есть. Если заполнение полей в приемнике зависит от полей источника, необходимое значение необходимо определить при выгрузке.

Структурное различие схем данных

Независимо разрабатываемые базы данных могут иметь несовместимую структуру (http://ru.wikipedia.org/wiki/Интеграция_данных).

• Различие в типах данных – например, код справочника в одной информационной базе может быть строкой, а в другой – числом. Если это только код, то можно вообще его не передавать и, проблема решена. Возможно, существуют другие примеры, где так легко их не обойти;
• Различие в единицах измерения – например, в одной БД указана величина в сантиметрах, в другой — в дюймах. Проблема также решается достаточно легко, вводом в правила сопоставления коэффициента пересчета;
• Различие во множестве допустимых значений – например, статусы объекта в одной базе (Не согласован, Подтвержден, Отгружен, Принят), а в другой (Не согласован, Отправлен, Выполнен);
• Различие «домен-отношение» — например, в одной базе значение строка, а в другой справочник. Проблему можно решить, если удастся автоматически заполнять необходимые поля в справочнике;
• Различие «домен — группа доменов» — примером проблемы может быть контактная информация, где в одной системе адрес хранится строкой, а в другой разбит «по частям» (дом, улица и т.д). Не всегда возможно написать универсальный алгоритм разделения одного поля на несколько;
• Различие «данные-схема» — метаданные одной базы данных не соответствуют метаданным другой базы данных. Например, в одной БД «инженер» — значение атрибута «должность» отношения «работник», в другой «инженеры» — отношение, содержащее некоторых работников, в то время как «бухгалтеры» — отношение, содержащее других. Так как схемы баз данных могут не иметь отражения между собой, то такое различие может оказаться непреодолимым. Например, одна база данных содержит регистр сведений Штрихкоды с измерением «Штрихкод» и ресурсом «Номенклатура», а другая с измерением «Номенклатура», а ресурсом «Штрихкод». В результате в первой базе не может быть одинаковых штрихкодов, а во второй – номенклатура не может иметь больше одного штрихкод.

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

Заключение

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

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

Решать проблемы интеграции мы предполагаем разрабатывая «модули интеграции». Данные модули будут дорабатывать типовые конфигурации под требования, предъявляемые нашими модулями.