На что обратить внимание разработчику DIRECTUM 5 при обучении DirectumRX

В связи с активным продвижением и ростом проектов DirectumRX, закономерно растет количество разработчиков, которые обучаются разработке на этой системе. Среди них значительную долю составляют прикладные разработчики имеющие обширный опыт по разработке на DIRECTUM 5.

По понятным причинам переход к разработке на DirectumRX — это не только смена ISBL на C#, но и перестроение в части подхода к проектированию. Учебный курс по разработке DirectumRX дополняется с каждой версией за счёт расширения тем, которые наиболее востребованы на проектах внедрения. После прохождения обучения прикладной разработчик обладает достаточным объемом знаний для адаптации системы под заказчика. Разумеется, курс дает крепкий базис, но не может учесть все нюансы, связанные в первую очередь с проектированием. Поэтому обучившиеся разработчики без наработанных практик применяют паттерны и приемы, сформированные в процессе адаптации систем на базе DIRECTUM 5. В данной статье собраны некоторые ситуации, на которые стоит обратить внимания разработчику при проектировании решений. Ситуации собраны в результате аудита проектных решений и рецензирования исходного кода разработчиков ISBL, прошедших обучение и начавших модификации на проектах внедрения DirectumRX.

Информация в разделах не является окончательно правильным решением, но рекомендуется к использованию в качестве ориентира.

Выделение абстрактного предка

В платформе DirectumRX изначально заложен механизм наследования сущностей. Любой разработчик сталкивался с внутренним вопросом: «Так, я делаю новый тип документа, от какой сущности делать наследника»? В простом случае в качестве предка выбирается конкретный тип документа, например, небольшие модификации дополнительного соглашения. Ситуации, в которых нужно наследоваться от базового документа, определяющего документопоток, требуют чуть более тщательного выбора и описаны в курсе.

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

• документ будет определять не конкретную сущность, а некоторый набор схожих;

• документы в рамках набора будут обладать разным набором свойств и разными правилами заполнения;

• есть ожидание, что при развитии системы модификации будут вноситься не в отдельные сущности, а во весь набор.

Примером может служить подтверждающий документ для авансового отчета. На реальном предприятии это может быть целый класс документов, которые заполняются по-разному в зависимости от ситуации. Для поездки на личном автомобиле нужно заполнять показания одометра, для брони гостиницы – даты заселения и выезда и т.п. Эти документы обладают общими характеристиками: необходимость связи с авансовым отчетом, наличием подотчетного лица и т.п. Но каждый из них при этом заполняется отличающимся способом. В этом случае, чтобы не закладывать логику через цепочки условных операторов («если вид подтверждающего документа – поездка на личном авто – отобразить группу контролов с показаниями одометра») целесообразно принять к рассмотрению вариант с абстрактным предком.

Предметные отображения вместо табличной части

В DIRECTUM 5 для реализации связи «объект – дочерняя коллекция» повсеместно используются табличные части. Этот способ применяется и в DirectumRX. При этом есть кейсы, при которых табличной части недостаточно. В этом случае отображение зависимых (или дочерних объектов) реализовано через предметное отображение.

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

• зависимые объекты формируются автоматически и не могут быть изменены напрямую из карточки сущности. Например, переписка по задаче в рамках регламента согласования.

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

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

Перекрытие регламента при реализации процесса «от документа»

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

Примеры доработок регламента приведены в статьях:

• DirectumRX Development Studio. Расширение возможностей регламентов согласования;

• Добавление новых результатов выполнения заданий при согласовании документов в DirectumRX.

Like-поиск с учетом классификаторов

При разработке DIRECTUM 5 типовым решением задачи «выбор записи с ограничением по классификаторам» было добавление в карточку объекта реквизитов для всех родительских классификаторов. Пользователь последовательно заполняет классификаторы, постепенно сужая круг доступных записей. В DirectumRX такой способ также доступен.

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

Отфильтровать сотрудников отдела закупок можно без добавления подразделения на карточку совещания.

Разумеется, такой способ подойдет не всегда. Так, например, если при выборе нужно отобразить сотрудников конкретного подразделения и только из него (бизнес-требование), то на карточку нужно выносить свойство «Подразделение» и настраивать фильтрацию.

Логирование

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

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

• любые интеграционные взаимодействия: подключение к другим системам (загрузка организационной структуры из SAP), обращение к сторонним сервисам (загрузка валют с сайта ЦБ РФ), работа со сторонними библиотеками (конвертация конструкторских документов в pdf) и т.п.;

• массовые операции надо объектами – переназначение прав на документы, рассылку о приближении срока актуализации лицензионных документов и т.п.;

• ход выполнения фоновых процессов.

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

Если у вас появились вопросы по приведенным рекомендациям или у вас есть свои лучшие практики, то приглашаю делиться в комментариях.

Ну и не забывайте, что репозиторий для справочника Person называется People :)