Один из универсальных способов интеграции DIRECTUM с внешними системами
Множество организаций до внедрения DIRECTUM предпринимали шаги по автоматизации специализированных процессов связанных с направлением своей деятельности. В большинстве случаев специализированные системы, внедрявшиеся в организациях были написаны "с нуля" в связи со своей узкой направленностью. И они вполне отвечают требованиям и выполняют необходимые функции.
При внедрении DIRECTUM обнаруживаются однотипные данные, которые присутствуют как в DIRECTUM, так и в своей системе заказчика. В этом случае пользователю приходиться выполнять ввод данных в обе системы, что вызывает у него естественную негативную реакцию. Как поступить в таких случаях? Как облегчить жизнь пользователю? Как внести минимальные изменения в привычную работу пользователя, и сохранить положительное отношения к инновациям у сотрудников заказчика?
В данном материале я приведу свое виденье решения описанных выше ситуаций и покажу детальный технический пример. А от читателей жду критики, новых идей и комментариев по обсуждаемой проблемме.
Вполне логичным решением проблемы является интеграция. И когда заходит речь об интеграции, первый поднимаемый вопрос - направленность интеграции. Двунаправленная интеграция подразумевает изменение данных как в DIRECTUM, так и в другой системе предприятия. Однонаправленная интеграция дает только "одну точку входа" изменений в одной из систем. Двунаправленная интеграция нужна, когда интегрируются специализированные данные и пользователям необходимо обрабатывать данные как в DIRECTUM, так и в интегрируемой системе. Т.е. разные процессы работы с одним типом данных протекают в разных системах. А в большинстве случаев наложение однотипных данных происходит в части стандартных справочников. Т.е. в части общих данных для большинства предприятий, например, договора, контрагенты и т.д., и здесь достаточно однонаправленной интеграции.
В этом материале рассматривается однонаправленная интеграция, т.к. синхронизируемые данные - стандартные. Однонаправленная интеграция имеет ряд преимуществ, получаемых в замен ограничения свободы изменений. Основными преимуществами являются:
- легкость поддержки порядка и актуальности данных. Т.к. имеется одна точка входа изменений, то есть определенная группа сотрудников вносящих изменения, что позволяет держать справочники "в порядке", исключая неактуальность и избыточность данных;
- меньшая трудоемкость реализации интеграции. Это позволяет экономить средства заказчика;
- поддержка безопасности. Например, специализированная система специализированного учреждения содержит очень конфиденциальную информацию и односторонняя интеграция от специализированной системы полностью исключает открытие возможности получения конфиденциальной информации через устанавливаемый канал обмена;
- скорость работы. В таком случае не требуется онлайн интеграция и ожидание отклика от системы получателя;
- нет необходимости разрешения конфликтов как в офлайн двусторонней интеграции
В качестве примера хотел бы привести однонаправленную онлайн интеграцию данных из учетной системы в DIRECTUM. Основными требованиями заказчика были независимость от учетной системы(ее структура может быть в будущем изменена) и одна точка входа данных (XML согласованной структуры, передаваемая в качестве параметра хранимой процедуры). Такие требования продиктованы отсутствием в учетной системе возможности выполнять некий код с использованием COM-серверов на определенном событии, и возможными кардинальными изменениями в учетной системе.
После анализа требований были приняты следующие решения:
- Необходимо установить четкую структуру передаваемой XML.
- Обработку XML производить сценарием DIRECTUM. Т.к. строго следует избегать изменение данных DIRECTUM на уровне SQL.
- Для обработки XML выгружать во временный файл.
- Поместить логику изменения записи, добавления записи, удаления записи в сценарий DIRECTUM.
- Обеспечить доступ из СУБД учетной системы к хранимой процедуре СУБД DIRECTUM посредством механизма Linked Server.
В результате порядок работы стал следующий:
- Подготовка XML заданной структуры в учетной системе.
- Вызов хранимой процедуры с передачей ей XML из СУБД учетной системы.
- Выгрузка XML во временный каталог
- Обработка времменого файла сценарием DIRECTUM, запускаемый из хранимой процедуры.
Таким образом, мы получили онлайн синхронизацию данных из учетной системы в DIRECTUM. При этом решение возможно масштабировать только за счет написания дополнительных сценариев DIRECTUM.
Предлагаю видео с техническими подробностями настройки интеграции.
Соглашусь с автором в том, что однонаправленная интеграция значительно проще в реализации двунаправленной. Но 100% защиту от конфликтов это даст не всегда.
Примеры уровня платформы:
1. Удаление записи может не пройти, т.к. она уже используется.
2. Изменение периода действия записи может не пройти, т.к. она используется и использующая запись также имеет ограниченный период действия.
Примеры прикладного уровня:
3. Реквизиты договора не могут быть изменены, т.к. по нему уже проведена оплата.
4. ИНН организации не может быть изменен на новое значение, т.к. есть другая организация с этим значением ИНН.
Конечно, все эти конфликты разрешимы, и при односторонней синхронизации чаще всего разрешать удается автоматически. Но тем не менее :)
А я не понял главного, в чем здесь универсальность? В этом варианте любое расширение формата данных - это разработка. Тот же коннектор на базе DIT был бы более универсален, т.к. позволил бы хотя бы на стороне DIRECTUM изменение формата решать на уровне настройки.
Еще очень смущает решение по п.5. - парсить XML в хранимой процедуре - мягко говоря выглядит очень странным...
Алексей, похоже, что XML парсит сценарий, а ХП только сохраняет файл и запускает сценарий.
Посмотрел видео, обнаружились еще такие вещи:
1. Использование ХП xp_cmdShell.
2. Явное указание логина/пароля в теле ХП.
В принципе, иногда такие вещи допустимы, но не всегда. И в любом случае должны использоваться очень аккуратно, о чем в статье ни слова. Например, надо ограничивать доступ к ХП xp_cmdShell, особенно если служба SQL сервера запускается с не сильно ограниченными привилегиями. Для таких сценариев должен использоваться специальный пользователь в DIRECTUM с максимально возможно урезанными правами, поскольку пароль хранится в открытом виде.
Изначальная задача была поставлена жестко: Пердача XML хранимой процедуре.
DIT также поребовал бы доработок доработок, возможно и большей трудоемкости. Универсальность в том, что система, формирующая xml, может быть любой.
Обработкой XML занимается сценарий DIRECTUM, а не хранимая процедура.
Не больше, чем создание этого же сценария. Но в дальнейшем при изменении требований, например при добавлении новых атрибутов к экспортируемым сущностям, достаточно было бы изменить настройку коннектора. А это любой заказчик смог бы выполнить самостоятельно.
Это не универсальность. Универсальность была бы в том случае, если бы сценарий импорта данных в DIRECTUM принимал данные от любой системы, и при этом не нужно было бы вносить изменений в код этого сценария. А описанный способ этого не гарантирует. Формат данных не описан, и скорее всего жесткий, т.е. не предполагает настройки. А любая другая внешняя система в 99% случаях будет требовать импорта данных с совсеми другими атрибутами объектов, требующих синхронизации.
Вызов ХП для передачи данных для импорта в систему DIRECTUM еще меньше делает данный способ универсальным, т.к. требует "допиливания" кода вызова ХП (в тексте явно задаются параметры сервера и БД DIRECTUM). Из видел ролика, похоже, что ХП написана для SQL сервера и не факт, что будет работать в других СУБД.
Раз уж зашла речь об универсальности, то неплохо бы рассмотреть вопрос написания собственного агента DICS для внешней системы.
Мне тоже интересно, особенно с учетом того, что такая задача как раз наклевывается и внешняя система работает с СУБД Oracle.
Так пока рассматривать особо нечего, не делали такого агента.
Дмитрий, можете воспользоваться документом с сайта поддержки - DICS 1.0. Разработка собственного агента.
Если есть доступ из СУБД учетной системы к СУБД Директума, почему бы не обмениваться данными через промежуточную таблицу? Чем обоснован жесткий выбор XML в качестве формата обмена?
1. Требованиями заказчика.
2. При конвертации на новую версию возможно затирание всех нестандартных таблиц.
Не в порядке критики, но как дополнение к случаям, когда заказчик ставит требования не столь жестко.
Решается выносом промежуточной таблицы в промежуточную БД. Как бы это странно ни казалось на первый взгляд, но администрировать дополнительную БД проще, чем связываться с администрированием доступа к файловой системе из SQL.
Подтверждаю. На одном из проектов уже столкнулись с такой проблемой.
Смею предположить, на основе существующего опыта, что в компаниях, где ИТ полностью на аутсорсинге, получение доступа к файловой системе и его администрирование вызовит ряд трудностей.
Еще одна "засада" заключается в том, что политика безопасности доменов и файловых систем аутсорсерами, особенно крупными, ведется без учета описанных в этой статье процессов, и высока вероятность, что в определенный момент SQL не увидит нужной папки.
Авторизуйтесь, чтобы написать комментарий