Среди требований заказчика при внедрении Directum RX часто бывает интеграция с системой 1С. А что делать, если таких систем не одна, а 2, 3…36 экземпляров. На первый взгляд такая ситуация кажется трудной, даже пугающей. Но это только на первый взгляд, на самом деле все немного проще.
В статье приведен пример работы с таким кейсом. Но для начала опишем общую схему работы интеграции Directum RX и 1С
Механизм синхронизации данных реализован в утилите DrxUtil. Утилита обеспечивает обмен данными с сервером приложений Directum RX через интернет, а с системой 1С через COM-соединение с помощью обработки «Универсальный обмен данными в формате XML». На изображении видно, что в рамках одной локальной сети обмен данными может проводится с несколькими базами 1С. Для каждой базы должен быть настроен файл _settings.xml, разработаны правила интеграции, которые используются утилитой DrxUtil, о чем будет написано ниже.
Основным и одновременно пугающим требованием заказчика N была интеграция 36 баз 1С с одним экземпляром Directum RX. Такое количество баз обусловлено тем, что каждая база – это самостоятельное юр. лицо. Во всех экземплярах 1С была установлена стандартная конфигурация 1С «Бухгалтерия предприятия», которая могла бы как-то повлиять на синхронизацию. Это позволило использовать стандартные правила коннектора 1С, который входит в набор утилит DrxUtil. Для каждого экземпляра 1С требовалось синхронизировать следующие типы сущностей:
Выполнялась односторонняя интеграция из 1С в RX.
Первым делом необходимо определиться на каком сервере будет проходит синхронизация между системами 1C и Directum RX. На этом сервере должны находится: платформа 1С, включая конфигуратор с подключенными для настройки базами 1С, утилита DrxUtil, а так же произведены настройки для COM – соединения между утилитой и 1С. Важно понимать, что независимо от количества баз 1С в синхронизации участвует один экземпляр DrxUtil, потому что параллельный запуск утилит может привести к ошибкам, т.к. утилиты могут одновременно работать с одними и теми же данными.
Далее реализовываем правила для синхронизации сущностей. Правила определяют логику выполнения переноса данных из одной системы в другую и выполняются при вызове сеанса интеграции. В них описан процесс импорта данных, поиска дублей, фильтрации и т.д. Более подробно можно почитать здесь. Правила находятся в папке Rules утилиты DrxUtil. Так как конфигурация для всех баз была идентичная, и требованиям заказчика по синхронизации удовлетворяли базовые правила, то в нашем случае оставалось только определить конструктор, в котором нужно прописать свойства конфигурации 1С. Пример правила для импорта контрагентов:
/// <summary>
/// Правило импорта контрагентов из 1С: Бухгалтерия предприятия 3.0 в DirectumRX.
/// </summary>
[Export(typeof(Rule))]
class CustomCompanyImport : CompanyImport
{
public CustomCompanyImport() : base()
{
this.Name = "CustomCompanyImport";
this.MinConfigurationVersion = "3.0.0.0";
this.MaxConfigurationVersion = "3.1.0.0";
this.ConfigurationTypes = new List<string> { "БухгалтерияПредприятия" };
this.SourceType1C = "Контрагенты";
this.TargetTypesRX = new List<Type>() { EntityTypesRXMetadata.CompanyType };
}
}
При необходимости в правилах можно реализовать методы фильтрации, импорта, в конструкторе явно указать необходимые нам реквизиты и т.д.
Со стороны прикладной разработки модификации не было. При необходимости можно добавить свойства сущностям, которые бы заполнялись при синхронизации, например, наименование базы, из которой была получена сущность при интеграции.
Собираем решение, добавляем библиотеку с кастомными правилами в папку Rules утилиты DrxUtil. На этом настройку правил можно считать законченной.
Следуем всем рекомендациям, указанным в справке о подготовке 1С к интеграции и настраиваем все конфигурации баз, которые участвуют в синхронизации. Но на одном моменте стоит обратить внимание – Идентификатор системы 1С. Для каждой конфигурации он должен быть уникальным! Это необходимо для того, чтобы сопоставлять созданные сущности в RX с записями определенной базы 1С.
Конфигурационный файл _configSettings.xml настраивается согласно рекомендациям. Настройку _settings.xml рассмотрим подробнее.
Для каждой интегрируемой базы должен быть свой файл _settings<Id_1C>.xml. Для удобства создадим в папке DrxUtil папку, которая будет хранить в себе настройки для каждой базы 1С. Важный момент в конфигурационном файле:
Секция параметров соединения с базой - Instance1C:
Узел systemId – в нем прописываем идентификатор системы 1С, для интеграции с которой используется текущий файл _settings<Id_1C>.xml Т.е. двух конфигурационных файлов с одним и тем же значением для этого узла не должно быть.
После настройки конфигурационных файлов для всех баз 1С создадим .bat файл, в котором опишем все необходимые запуски DrxUtil. Пример:
На изображении видно, что один экземпляр DrxUtil запускает процесс синхронизации, используя для каждой базы свой файл настроек. Данные процессы запускаются последовательно, т.е. пока не завершится текущий следующий процесс не начнется. Данный bat-файл можно запускать вручную, а можно создать в планировщике Windows задание для автоматического запуска интеграции с базами 1С, указав в запускаемом файле наш bat-файл. При первом переносе данных мы запускали файл вручную для отслеживания результатов, о которых будет написано ниже. Синхронизация продолжалась довольно долго, так как в базах находилось достаточно записей для синхронизации.
Основной проблемой стало то, что базы 1С заказчика между собой никак не синхронизировались. Так же в разных базах использовалась разная методика работы с данными, например, если изменилось наименование контрагента могли добавить новую запись, не закрыв старую, в другой базе не были заполнены полные наименования записей, в третьей записи создавались правильно - старая запись закрывалась, новая использовалась как действующая. По этим причинам в RX начали заноситься некорректные данные, возникали дубли.
Так же ярким примером служат банковские счета. Из 1С они передаются в связке с банком, но банки расценивались при импорте как дубли, т.к. в RX уже существовали банки из других баз, поэтому не для всех контрагентов импортировались счета.
Необходимо учитывать подобные моменты при синхронизации. Если дописать правила, то такие моменты можно максимально нивелировать. Но все же лучше устранять дубли в базах 1С, синхронизировать их между собой. Сделать это позволяет внутренний функционал 1С, поэтому перед синхронизацией с внешней системой, желательно предложить заказчику «навести порядок» в его базах.
Подводя итог, можно сказать, что синхронизация Directum RX с несколькими базами 1С вполне возможна - мы это доказали, но к этому нужно хорошо подготовится. Спасибо за внимание, надеюсь статься была интересная.
Вадим, хорошая статья. Проблемы при синхронизации нескольких баз 1С описаны, но очень интересно смогли ли их как-то решить и, если да, то как? Вот, к примеру: "По этим причинам в RX начали заноситься некорректные данные, возникали дубли". Не пытались как-то вычленять дублирующие записи?
Еще очень интересен следующий вопрос, а что, если бы часть из этих 36 баз 1С была кастамизирована или инсталляции 1С имели разные версии? Как существенно это могло бы повлиять на работоспособность описанной схемы? И не пришлось бы в таком случае отказываться от варианта с коннектором в пользу реализации веб-сервисов интеграции? Понятно, что трудоемкость в данном случае была бы не соизмерима, но все же...
Спасибо за статью! Хорошо, когда синхронизация выполняется в одну сторону. Но выглядит странно, что договоры синхронизируются из 1С в Directum RX, а не наоборот. У меня был такой кейс: контрагент заводился в одной базе 1С, передавался в Directum RX, где создавался и утверждался договор. После подписания договора, он передавался в 2 базы 1С: где велись контрагенты и в базу, где создавались заказы на закупку. Можно ли такой кейс решить с помощью разработки описанных правил?
Ксения, по ситуации "договоры синхронизируются из 1С в Directum RX, а не наоборот". Такой механизм можно использовать, при начальном наполнении Directum RX, например для импорта карточек исторических договоров из существующей (-их) баз 1С у заказчика. Настраиваем интеграцию с 1С - проводим сеанс интеграции - получаем список договоров в Directum RX - отключаем интеграцию. Такой вариант подойдет, если очень трудоемко использовать утилиту импорта или создавать отдельный механизм миграции исторических данных.
Ксения, на данном проекте интеграцию договоров из 1С в Directum RX запустили только один раз, для миграции исторических договоров. После миграции синхронизация с помощью коннектора была отключена.
После подписания договоры из RX вручную переносятся в 1С. Так захотел сам Заказчик, и на это у него были причины, но к сожалению озвучить их не могу.
Василий, изначально заходили в проект с таким условием, что все базы 1С не кастомизированы, поэтому и работы на адаптацию коннектора не закладывали.
На самом деле уверенности, что все успешно получится у проектной команды тоже не было, такой кейс ранее не тестировался. Поэтому шли на риск.
Очень жаль, что из-за "бардака" в контрагентах, который творился в базах 1С постоянную синхронизацию пришлось отключить, чтобы не получить еще одну помойку. Но после наведения порядка, запустим опять.
Тимур, понятно. Да, я тоже подумала про первичную миграцию, но надеялась, что и синхронизация на регулярной основе возможна. В нашем кейсе мы осуществили интеграцию с одной базой 1С, где велись контрагенты. Экспорт из Directum RX осуществлялся через веб-сервисы, в формате xml, а Заказчик своими силами на стороне 1С реализовал веб-сервисы для получения и обработки xml. Делалось это по кнопке из карточки Договора.
Вадим, спасибо за интересную статью! Интересует следующий вопрос: подойдет ли такая схема интеграции для ситуации, когда в ходе продолжительной работы в системе возникла необходимость синхронизироваться с еще одной базой 1С? И нужно ли учитывать в этом случае еще какие-то риски, помимо дублирования записей?
Василий, Если какие-то конфигурации кастомизированы, либо имеют другую версию, то можно написать конкретные правила импорта для этих конфигураций и указать их в _settings.xml - файлах. Тут все зависит от конфигурации 1С. Был случай с нестандартной 1С, когда возникали проблемы при интеграции. Оказалось, что внутри конфигурации были проверки доступа к справочникам и только определенные пользователи могли получить эти данные, а пользователь, через которого проходил обмен, не подходил под критерии этих проверок, хоть и обладал админскими правами. Поэтому перед интеграцией необходимо убедится, что конфигурация 1С позволит обмениваться данными с внешней системой.
Светлана, Думаю, подойдет, если с сервера, где проходит обмен между системами, будет доступ к подключаемой базе 1С. Нужно будет настроить интеграцию с новой базой по аналогии с существующей.
Из рисков, кроме дублей, стоит учитывать те данные 1С, которые связаны между собой ссылками. Пример: в одной базе 1С есть сущность "Банк", а в другой базе такой же банк, но он связан по ссылке с банковским счетом. При импорте из первой базы 1С в RX создастся банк, а при импорте из второй базы банк отфильтруется как дубль, а банковский счет останется без "хозяина", т.к. ссылка будет указывать на отфильтрованный банк и соответственно счет не создастся. Основные риски зависят от содержимого баз, которые синхронизируются.
Вадим, расскажи подробнее, почему создаются дубли банков. Ведь можно импорт банков настроить по ключевому реквизиту БИК и тогда при импорте записей коннектор должен найти существующий банк и создать для него только связь с записью 1С.
Авторизуйтесь, чтобы написать комментарий