Перенос данных между системами Directum RX вещь весьма актуальная. Не так давно компания Directum выпустила свое техническое решение Утилита для переноса справочных данных Directum RX.
В нем все хорошо, за исключением момента. Когда планируется переносить кастомные или доработанные справочники, то без участия прикладного разработчика не обойтись.
Кто работал на Directum 5 и ниже, еще помнят механизм переноса справочников, выбрал что нужно, экспортировал и готово. Работало это не идеально, но с точки зрения использования механизм был весьма прост для "пользователей" (консультанты, тестировщики, администраторы и т.д.). И казалось странным, почему похожего механизма нет в RX.
Вызов принят )))
Как работает решение, буду показывать на примере справочника "Журналы регистрации", где предварительно создал пару тестовых записей.
1) Заходим в обложку модуля "Перенос данных".
2) Запускаем диалог "Экспортировать записи":
a) выбираем справочник;
б) выбираем сколько и какие записи мы хотим экспортировать;
в) заполняем состав значимых реквизитов, по которым будет осуществляться поиск в другой системе;
г) нажимаем "Экспорт".
В результате экспорта получаем Zip-архив с XML-документом.
3) Переносим XML-документ на другую систему: запускаем диалог "Импортировать записи" и выбираем экспортированный XML.
По результатам импорта формируется отчет.
4) Проверяем результат - заходим в справочник "Журналы регистрации".
После проведения нагрузочного тестирования и шлифовки мелких деталей, опубликую исходники на Club или GitHub Directum.
Но так как проектирование, разработка и тестирование ведется на 95% в свободное от работы время, которого особо нет, публикация может несколько затянуться.
Что планируется сделать, но пока не дошли руки:
Изначально поставленные цели на мой взгляд, вроде как, достигнуты.
Насколько решение окажется жизнеспособно, покажет комьюнити Directum RX.
Беляков Сергей
Опубликовано:
20 января 2022 в 07:36
Обсудите реализацию с экспертом Directum
Комментарии (11)
Можно уточнить как перебираете кастомные и перекрытые объекты? Кажется это одна из самых непонятных штук (по крайней мере с опытом разработки в RX менее года) во всей разработке.
Антон, Там ничего сложного на самом деле нет.
В таблице Sungero_System_EntityType перечислены все Guid-ы типов и интерфейсы существующих в системе объектов.
Используя эти данные и метаданные базового объекта (например Sungero.CoreEntities.IDatabookEntry) можно построить весь список наследования, включая перекрытия.
Т.к. эта операция относительно ресурсоемкая, она вынесена на этап инициализации, поскольку обрабатывать весь массив данных где-то в диалоге, не имеет никакого смысла, поскольку без публикации разработки новые объекты в системе не появятся.
Будут вопросы, пишите.
Сергей, доступ к таблице через объектную модель можно получить или проще запросом получить данные?
Антон, Я запросом данные получал.
Сергей, Руслан, скорее постите свой статус https://www.instagram.com/p/CZwOlV5qJsM/ Это про вас
Сергей, когда планируете выложить на GitHub?
Ансель, Судя по текущей проектной загрузке, раньше мая не появится точно.
Скорей всего выйдет летом, как одна из частей нового решения для администраторов.
выглядит полезно : ) Несколько моментов пока не поняла, могли бы пояснить:
1. Сейчас при импорте создаются дубли? В отчете отображается, что запись является дублирующей, но не понятно, повторная запись не создается вообще или заменяет ранее созданную? Что если в новой импортируемой записи есть небольшие отличия от уже созданной, при загрузке сравниваются все реквизиты?
2. Не до конца понятно назначение "значимых реквизитов" в диалоговом окне экспорта. На видео вы показали экспорт сотрудника и указали значимым реквизитом эл. почту. По ней идет поиск дублей при загрузке или что? Поиск по имени не используется для поиска дублей, только для поиска дочерних записей?
3. Сейчас есть какие-то ограничения на количество выгружаемых записей?
Екатерина, Добрый день.
1) Нет, дубли в системе не создаются.
Все отличия между существующей записью и импортируемой на данный момент игнорируются.
Запись в отчете наверное стоит поменять на более понятную )))
2) Возможность выбора значимых реквизитов нужна для того, чтобы повысить точность поиска дублей в другой системе и предоставить возможность задавать критерии этого поиска.
К примеру, если при импорте персон ориентироваться только по стандартному полю "Наименование" (Name), то записи с одинаковыми Ф.И.О. будут пропущены, при том что это могут быть разные люди.
Связка из 2-х и более реквизитов позволяет сделать каждую запись уникальной.
А где-то наименование вообще никакой роли не играет, там свой набор реквизитов.
3) Ограничений замечено не было, но быстродействие напрямую зависит от ресурсов сервера.
Импорт 3000 записей справочника "Подразделения" выполняется где-то за 20 секунд +/-.
Сергей, спасибо за ответы, теперь понятно
Добрый день, не нашел на гитхабе ваше решение, есть какая-то информация на данный момент по статусу модуля? Готов, тестируется, больше не развивается и тд. Если модуль готов, где можно его посмотреть, поюзать?
П.С.: нашел новую статью по данному решению, вопрос снимается.