Развитие инструмента разработки в DIRECTUM 5.5
В этой статье мы рассмотрим новинки, которые оценят разработчики: создание своих прикладных методов, история переноса разработки, тип реквизита «Документ», блок «Пауза» и другое.
Прикладные методы – упрощаем разработку
В предыдущих версиях DIRECTUM при разработке на ISBL можно было использовать только системные методы. Они поставляются вместе с платформой IS-Builder. Например, IEDocument.Open – метод Open объекта IEDocument.
Для упрощения десктоп- и веб-разработки в DIRECTUM 5.5 появилась возможность создавать свои методы с параметрами и возвращаемым результатом. Такие методы называются прикладными.
Ранее для выполнения в веб-клиенте ISBL-вычислений с параметрами и возвращаемым результатом требовалось использовать сценарии и функции, которые создавались отдельно от текущей компоненты. Сейчас те же задачи можно решить с помощью прикладных методов.
Метод можно вызвать как в вычислениях ISBL, так и из внешнего приложения:
- вызов метода в ISBL:
Reference = References.ОРГ.GetComponent
Result = Reference.OnExecute_ПоискЭД()
- вызов метода в веб-разработке:
WA.current.executeEntityMethod("MethodName", param1, param2, ..., paramN).done(
function(res){
console.log(res);
});
Кроме того, прикладные методы обеспечивают простое повторное использование вычислений. Метод можно вызвать в различных действиях и методах.
Прикладные методы создаются в компонентах Типы справочников, Типы карточек документов и Диалоги. У действия появилось обязательное свойство Вычисление, в котором указывается метод, выполняемый при вызове этого действия:
Для действий, созданных в предыдущих версиях, методы будут созданы автоматически при обновлении на DIRECTUM 5.5.
Расширяем возможности реквизитов
Реализована идея с сайта DIRECTUM Club: появился новый тип реквизита «Документ». Реквизиты этого типа хранят ссылки на документы системы. По аналогии с выбором записи справочника теперь можно настроить и выбор документа. Для этого необходимо задать вычисления в событиях «До выбора» и «После выбора». Добавлен объект IDocRequisite.
Для работы с целыми числами в диапазоне от -2^63 до 2^63-1 появился тип реквизита «Большое целое число». Например, реквизит этого типа используется для хранения размера документа в байтах. Добавлены объекты ILargeIntegerRequisite, ILargeIntegerValue, ILargeIntegerCriterion и тип данных rdtLargeInteger. Свойство IEDocumentVersion.Size теперь возвращает значение типа «Большое целое число».
В распределенных системах организации бывают разнесены по разным часовым поясам. Чтобы при разработке учитывать это, для реквизита типа «Дата» реализована поддержка времени в формате UTC. Для преобразования локального времени в UTC и обратно используются новые ISBL-функции LocalTimeToUTC и UTCToLocalTime. При создании реквизита с помощью метода CreateDateTimeRequisite теперь можно задать тип времени: локальное или в формате UTC.
Ставим типовой маршрут на паузу
Новый базовый блок «Пауза» предназначен для приостановки выполнения текущей ветки типового маршрута:
Выполнение типового маршрута продолжается после наступления крайнего срока или программно. Чтобы продолжить выполнение программно, используйте методы ITask.ResumeFromPause или ITask.ResumeFromPauseByBlockID.
В предыдущих версиях DIRECTUM уже были схожие по своему назначению блоки «Мониторинг» и «Ожидание». Рассмотрим, в чем разница между ними и новым блоком.
Задачи на блоке «Мониторинг» остаются в очереди службы Workflow. Если заданное условие долго не выполняется и таких задач накапливается много, то они начинают мешать обработке остальных задач. При наступлении события выход из блока «Мониторинг» происходит не сразу, а через указанный в настройках интервал мониторинга.
При использовании блока «Пауза» очередь задач не растет, задания быстро приходят пользователям. Это связано с тем, что служба Workflow не обрабатывает задачи, которые находятся на этом блоке. Выход из блока «Пауза» происходит сразу после выполнения метода объектной модели.
Блок «Ожидание» приостанавливает выполнение типового маршрута на заданный срок. Блок «Пауза» позволяет программно продолжить выполнение маршрута до наступления крайнего срока.
Итак, используйте блок «Пауза», если требуется:
- снизить нагрузку на службу Workflow;
- дождаться выполнения события, которое может произойти в любую минуту, либо на него нужно оперативно среагировать.
Например, есть справочник и типовой маршрут, которые автоматизируют процесс общения с контрагентами. В ходе типового маршрута запрашивается информация у контрагента, выполнение задачи останавливается на блоке «Пауза». Когда от контрагента поступает ответ, запись справочника переходит в другое состояние, срабатывают вычисления справочника в событии «Сохранение После». В результате находится связанная задача и продолжается ее выполнение.
Контролируем перенос разработки
В организациях, активно ведущих прикладную разработку, контроль переноса разработки является важной задачей. Для ее решения в DIRECTUM 5.5 появилась компонента История переноса разработки:
По кнопке Открыть карточку можно посмотреть список элементов разработки, перенесенных в рамках пакета.
При экспорте разработки каждому пакету присваивается код. Если для корректного приема данного пакета необходимы элементы разработки, переданные ранее в другом пакете, то надо указать код этого пакета в поле Зависит от:
Новый пакет нельзя импортировать, пока не принят пакет, от которого он зависит.
Ускоряемся!
В предыдущих версиях администраторы и разработчики сталкивались с тем, что перенос больших пакетов разработки занимает довольно много времени. Например, об этом сообщалось при обсуждении статьи. В DIRECTUM 5.5 ускорен перенос разработки с помощью утилит Экспорт разработки и Импорт разработки. Экспорт стандартного пакета разработки DIRECTUM ускорился в 40 раз, открытие стандартного пакета при импорте – в 15 раз.
Вызов прикладных ISBL-функций в цикле стал быстрее за счет снижения затрат на вызов функции в 50 раз (с 1 мс до 0.02 мс). Это заметно влияет на общее быстродействие, когда функция без «тяжелых» вычислений вызывается в цикле сотни раз.
Чтобы узнать больше о новинках, обратитесь к закрепленному менеджеру или воспользуйтесь формой «Заказать демонстрацию» на нашем сайте.
Ждем ваши вопросы и комментарии. Следите за новыми материалами о DIRECTUM 5.5!
И сразу возникает вопрос:
Для документов методы сделали. Для справочников сделали. Для диалогов даже сделали. А для задач и заданий?
У них ведь так же есть действия. Почему бы не сделать единообразное поведение и для задач с заданиями?
>> Почему бы не сделать единообразное поведение и для задач с заданиями?
Может быть, это из-за того, что документы, справочники, диалоги типизированы более жестко, чем задачи/задания? Типизация задач/заданий по типовым маршрутам будет довольно "расплывчатой", как мне кажется. Или Вы имеете в виду методы сразу для всех задач и заданий, без "деления" на "классы"?
А еще у меня есть вопрос - обратил внимание, что названия методов, которые соответствуют действиям, начинаются с OnExecute. Это логично, т.к. в таком стиле обычно именуют обработчики событий, а методы, соответствующие действиям, выполняются как бы "по событию" - при выполнения действия.
А есть ли какие-то "соглашения" по именованию методов, не связанных с действиями?
>>Может быть, это из-за того, что документы, справочники, диалоги типизированы более жестко, чем задачи/задания? Типизация задач/заданий по типовым маршрутам будет довольно "расплывчатой", как мне кажется. Или Вы имеете в виду методы сразу для всех задач и заданий, без "деления" на "классы"?
Типизированы ровно так же, как и документы или справочники. Вы точно так же можете создать некоторый метод X у одного типа документа, но не создавать у всех остальных. С задачами или заданиями я вижу ту же ситуацию.
Ну например, описанный выше функционал блока паузы. Очень удобный функционал, необходимость в котором раньше возникала. Допустим, у нас есть ТМ, который создает N записей справочника и переходит в режим паузы. При смене состояния записи, мне бы хотелось "пнуть" задачу. Пнуть - значит произвести проверку, что все записи изменили состояние и только после этого двигаться с блока паузы дальше. В этом случае, такой поверке, например, самое место в методе задачи.
Понятно, что можно сделать проверку в событии справочника. Или в действии задачи. Но идеально бы оно смотрелось именно в методе задачи.
Поясните, пожалуйста, зачем сделали отдельный блок "Пауза", а не доработали блок "Ожидание". Даже сейчас костылями можно прекратить блок ожидания и отправить задачу дальше.
>> Для документов методы сделали. Для справочников сделали. Для диалогов даже сделали. А для задач и заданий?
Спасибо, зарегистрировали пожелание на следующие версии.
Потому что в справочниках и документах они были нужнее и реализация однотипная (диалоги вообще практически "бесплатно" достались), в задачах ситуаций было меньше и реализацию нужно делать слегка другую. Возможно в будущих версиях системы и до задач доберёмся.
Блок пауза, если нет крайнего срока, вообще пропадает из очереди Workflow. При этом у блока пауза выход по крайнему сроку это скорее отрицательное выполнение блока, у ожидания положительное. В принципе ожидание можно было доработать (даже не совместимостей можно было избежать), но показалось более логичным сделать новый блок со своими выходами и новой ОМ.
>> Типизированы ровно так же, как и документы или справочники.
Если речь о типизации задач за счет типовых маршрутов, то не совсем "ровно так же". У каждой записи справочника есть тип справочника и у каждого документа есть тип карточки ЭД. При этом если в ТС/ТКЭД внесены изменения, они автоматически распространяются на все соответствующие записи/документы. С задачами ситуация немного другая. Во-первых, не все задачи имеют связь с ТМ. Во-вторых, если в ТМ внесены изменения, то они не распространяются автоматически на все задачи по данному ТМ. То есть, если в гипотетические прикладные методы типовых маршрутов вносятся изменения, то возможно наличие в системе множества задач с индивидуальными реализациями одного и того же метода. Представьте ситуацию "есть много задач по одному и тому же ТМ, у этих задач есть метод с одним и тем же наименованием, но у каждой задачи своя уникальная реализация этого метода".
>> Ну например, описанный выше функционал блока паузы. Очень удобный функционал, необходимость в котором раньше возникала. Допустим, у нас есть ТМ, который создает N записей справочника и переходит в режим паузы. При смене состояния записи, мне бы хотелось "пнуть" задачу. Пнуть - значит произвести проверку, что все записи изменили состояние и только после этого двигаться с блока паузы дальше. В этом случае, такой поверке, например, самое место в методе задачи.
Пример не очень удачный чисто по техническим причинам. Т.к. пинок задачи происходит из обработчика события изменения реквизита записи справочника, то есть до сохранения измененного значения в базе, то прикладной метод задачи, проверяющий значения реквизитов этих N записей, не увидит данного изменения и не сработает.
В целом я не настроен категорически против, как может показаться. Наверное, прикладные методы задач и правда могут быть полезны для инкапсуляции некоего прикладного кода, вызываемого из разных мест. Но считаю, что надо еще поработать над аргументацией и юз-кейсами. Это вполне подходящая задача для коллективного разума Клуба :)
Доброго всем дня!
Для нового реквизита "Документ" недостаёт отдельной визуализации на форме. Сейчас для указанного документа можно штатно открывать карточку, а для просмотра текста по-прежнему нужно будет городить что-то сверху (или переопределять события, или использовать методы и действия).
>> Для нового реквизита "Документ" недостаёт отдельной визуализации на форме. Сейчас для указанного документа можно штатно открывать карточку, а для просмотра текста по-прежнему нужно будет городить что-то сверху (или переопределять события, или использовать методы и действия)
Открытие есть:
- в десктоп-клиенте делается через Shift+клик на кнопку или через Shift+F4 (достаточно неочевидно в первый раз)
- в веб-клиенте в контроле отдельная кнопка для открытия документа.
Документ как реквизит это 5. отлично можно не пользоваться связанными документами
При удалении документа будет проверка на использование?
Нет не будет. И визуальной разницы между отсутствием документа и отсутствием прав нет.
Нет не будет. И визуальной разницы между отсутствием документа и отсутствием прав нет.
поясните. если в реквизите указан документ на который у пользователя нет прав, то при открытии карточки с таким реквизитом/обращению к нему что будет происходить?
В контроле (или в колонке списка) будет написано "Объект удален или у вас нет прав". При попытке открыть карточку документа или сам документ тоже будет ошибка. Указать в качестве значения реквизита другой документ при этом можно.
В ISBLScan.ViewCode добавлена поддержка методов.
Авторизуйтесь, чтобы написать комментарий