Быстрое сохранение схем ТМ: как это было

Андрей, день добрый.

Думаю, про качественный прорыв - это вы поторопились. Сейчас в техподдержке от нас в работе тикет 61878. В кратце: при сохранении схемы "тяжелого маршрута" sbrte.exe отъедает почти 2 ГГб оперативной памяти и падает с ошибкой. Если это называть качественным прорывом, тогда да, раньше sbrte не падал. Даже Core i7 и 16Ггб оперативы не выручают 

Вот цитата из последнего сообщения от ТП:

Очень интересно было бы посмотреть на такие схемы.

Андрей, а можешь подробнее рассказать откуда вообще берется такая проблема. Если это конечно не корпоративная тайна :)

Я видел маршруты, которые по несколько дней сохранялись. Несмотря на их запутанность и обилие блоков, я считаю, что это не те графы, на которых могут спотыкаться современные машины. Поэтому интересно на, что проверяется граф и какие происходят дополнительные вычисления.

Очень интересно, на что проверяется схема, зачем она проверяется, и что это за штука такая - "расстановка блоков начала цикла".

Давайте расставим все по местам:

1. Проверка схемы ищет циклы с двумя входами. Такая ситуация считается недопустимой и Workflow ее не сможет обработать. Где-то на форуме даже был пример такого ТМ с вопросом "Как исправить?"
2. Расстановка блоков начала цикла нужна для двух вещей: а) определить к какому циклу относится блок и б) определить вложенность циклов. Это все нужно опять же для последующей корректной обработки ТМ на Workflow. Результаты проверки записываются в схему (вроде бы, узел ExecutedBlocks, если я ничего не путаю).
3. Эти операции очень разные и могут выполняться в разные моменты времени, так что совместить их не получится.
4. Соответственно, на скорость обработки и расход памяти под эти алгоритмы влияет только количество блоков и их расстановка (циклы). Типы блоков и прикладной код - не влияют (но, конечно, они влияют на другие операции, связанные с сохранением ТМ). Михаил, если в указанный вами тикет - это та ситуация, на которую я ссылался в начале статьи, то там все должно отлично работать. Давайте проверю еще раз. Вдруг мне передали неправильный ТМ.
5. Как правило сложные ТМ нужны когда хотят совместить несколько связанных бизнес-процессов в один (избавляются от подзадач). Например, это могут сделать для линейной переписки в задаче (без разветвленного дерева).
6. Написать ТМ, который гарантировано будет проверяться слишком долго (или гарантировано превысит память на указанные алгоритмы) можно, но непонятно зачем. Это надо будет написать несколько сотен (точно больше 300) блоков и несколько сот тысяч вариантов прохождения маршрута (из-за циклов). Кстати, 16 Гб памяти на машине разработчика никак не помогут. Процесс 32-битный и не может использовать больше 2 Гб.

Коллеги, пользуясь случаем хотел бы уточнить ограничение по поводу "цикл не может иметь несколько входов", которое преследует разработчиков с самого начала Directum. Конечно любой маршрут извратясь можно переделать для избавление от этой "особенности", увеличив кол-во блоков (иногда практичеки двое), однако имхо это не есть хорошо. Тем более с точки зрения здравой логики(не касаясь алгоритмов проверки, которая прикладного разработчика или консультанта не интересует) не ясно , почему Directum накладывает такое ограничение. То есть получается, что продукт ограничивает  сложность БП, вместо своего прямого назначения - автоматизации (и кстати оптимизации) процесса, что в принципе не корректно.

Андрей, складывается впечатление, что вы решаете некоторую сверхзадачу, которую сами себе и поставили. Вот ты пишешь - "Такая ситуация считается недопустимой и Workflow ее не сможет обработать". Ну так пусть она её и не обрабатывает, если не может. Пусть задача "упадёт". Вполне понятна ситуация, когда задача прекратилась с ошибкой. Разработчик маршрута пересмотрит схему и внесёт изменения. Работа у него такая и инструмент разработки не должен ему мешать. За те сутки, на которые редактор схемы маршрута уходит "в себя", разработчик мог бы опробовать на работоспособность несколько вариантов схемы и найти подходящую. Вместо этого вы, руководствуясь вроде бы благородными целями, по факту отбираете у разработчиков маршрутов возможность контролировать процесс.

По пунктам:

1,2,3) Да какая мне разница что вы там проверяете? Если ТМ отработал корректно, значит я правильно разработал схему. Если воркфлоу не может обработать схему, пусть задача по этому ТМ упадет и скажет почему она упала.

4) С этой ситуацией мы боремся уже четвертый год. Выгрузку маршрута я присылал новую по этому тикету. Это то, что сейчас работает по трем подзадачам (хотел эти части объединить), но хочу заметить, что это подзадачи не логические, а "вынужденные".

5) Это согласование одного из видов договорного документа. Да - это очень большое количество согласующих (в зависимости от различных условий согласующие разные), да - наверное, это неправильноэ. Но повлиять и уменьшить количество согласующих я не могу.

6) 

8) Нашла коса на камень :) Ждем вендора 8) Это уже не локальный двухнедельный разбор ТМа со службой SD directum (к ним кстати никаких замечаний) с одним результатом "меняйте ТМ" 

По поводу падения задачи на Workflow: Евгений, Михаил, это у вас ситуация допустимая, а в других организациях - нет. Если система сказала разработчику, что его маршрут рабочий, падения в ходе работы из-за "кривости" схемы быть не должно.

И давайте все-таки отделим мух от котлет. Если наша оптимизация где-то не работает - будем разбираться. Но чем плоха быстрая проверка маршрута, я не понимаю. Совсем. Если вы видите ее недостатки - укажите их, пожалуйста. Только конкретно, а не просто "не нравится".

PS. И да, я все еще в отпуске. Пока не выйду - разобраться с проверкой ТМ не смогу

"По поводу падения задачи на Workflow: Евгений, Михаил, это у вас ситуация допустимая, а в других организациях - нет. Если система сказала разработчику, что его маршрут рабочий, падения в ходе работы из-за "кривости" схемы быть не должно." - я считаю алгоритмы проверки ТМ не должны накладывать ограничения на логику ТМа вообще. Если задача зациклилась или упала - это исключительно на совести разработчика ТМа. Это важно, т.к. достаточно часто получается красивый и эргономичный ТМ, но с несколькими входами в цикл. И приходится делать его громоздким и избыточным (что во-первых увеличивает возможность ошибки разработчика, во-вторых - делает ТМ тяжелочитаемым, в-третьих - увеличение сроков отладки).

Даже отключал проверку и пытался установить признак корректности напрямую в базу, но что-то не припомню, к чему в итоге это привело.

PS. Андрей, очень извиняемся - отпуск - святое. Возвращайтесь и спокойно продолжим диалог, много версий терпели такое поведение системы, доживем.

Всем хороша, но я ее не видел .

Да, очень верно, с этим никто и не спорит, - если система сказала, то тогда, конечно, падений быть не должно. Проблема в том, что прежде чем что-то сказать, система уходит подумать. Иногда уходит надолго. И вот тогда возникает вопрос - может ей и не говорить ничего?

Да, падение задачи в рабочем режиме недопустимы. И решается это тестированием маршрута.

Андрей, вот честно, не очень понятна защищаемая вами идея. Вот взять тестовый редактор. Написали в нём скрипт и нажали кнопку "сохранить". Вполне ожидаемо, что редактор просто сохранит файл и не уйдёт на пару часов "в отключку" для выяснения работоспособности скрипта.

Андрей защищает правильную идею. Надо понимать, что посыл у проверки ТМ'а - избавить разработчика от ошибок. Время сохранения - косяк, косяк который можно и нужно исправить. А отказаться от проверки, это не решение проблемы. Вы бы отказались от проверки синтаксиса в редакторе? (прошу не надо комментов типа "да если это занимает пол часа", я об этом уже написал)

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

А теперь вопрос снова Андрею. Все-таки по прежнему не понятна сложность задачи. Из вашего описания следует, что решается задача поиска циклов в ориентированном графе? Это вроде как NP полная задача, но граф в 1000 вершин это не проблема на пол часа для современного компьютера или я ошибаюсь?

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

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

"Данная ошибка просто показывает, что программист некорректно изложил бизнес процесс на языке редактора." данная ошибка просто показывает, что цели продукта - не помочь автоматизировать процесс, описанный в самом простом, понятном всем виде ( наподобие стандарта BPMN), а жестко соответствовать логике КОТОРАЯ В ГОЛОВЕ У РАЗРАБОТЧИКА.

Андрей Шилов, я Вам напомню, что продукт создавался для удовлетворения потребностей Заказчика, который деньги платит в том числе и Вам. Я Вам говорю о том, что с используемыми ограничениями бизнес-процесс четко описанный (пусть будет в том же BPMN) БП рождает урода и монстра в DIRECTUM, а Вы мне "разработчик ТМа дурак - программа так должна работать".

Простите, ошибся, посыл Александру 8)

Простить то прощу, но осадок остался

это производственные издержки .. главное - правда за нами - мы победим!  

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

Ваше сравнение редактора ТМ с нотацией BPMN притянута за уши. Вы же не сравниваете бизнес требования написанные в word с их реализацией на isbl?

Редактор ТМ это в первую очередь инструмент разработки, а уж во вторую очередь визуализатор процесса для пользователя. Откуда вам знать, что нарисованная в BPMN схема логически корректна? Еще раз повторюсь (пусть если я не прав, разработчики меня поправят и я готов буду принести извинения): наличие двух входов в цикл - это потенциально, то место где может возникнуть неопределенность в последовательности выполнения блоков маршрута. Это равносильно некорректному  синтаксису в редакторе кода. Вы же не начинаете тестировать сценарий с ошибками синтаксиса, типа "а, все равно с первого раза не заработает"?

Александр, уверяю, никто Вас "не переходил", мой персональный ответ - ничего страшного не несет, и конечно извиняюсь, если напряг.

"Редактор ТМ это в первую очередь инструмент разработки, а уж во вторую очередь визуализатор процесса для пользователя. " - редактор ТМ в первую очередь - это реализация требований бизнеса (как и весь Directum). С этим я надеюсь, Вы не будите спорить, утверждая, что это инструмент разработки, который должен работать и выдавать результат в такой форме, которую считает корректным разработчик платформы.

"Откуда вам знать, что нарисованная в BPMN схема логически корректна?" - я рассуждаю, опять же, с точки зрения бизнеса - ну есть у Заказчика процессы, имеющие циклы с несколькими входами, значит сие имеет место быть, следовательно и продукт должен соответствовать этому, потому, что продукт для Заказчика а не наоборот (по крайней в случае с СЭД DIRECTUM). Кстати с этой точки зрения я и  "притянул за уши" редактор и BPMN.

На основании этой простой мысли(что сначала был БП )  я и утверждаю, что система должна поддерживать обработку подобных схем. Кстати в документуме, нинтексе (шарпоинте), альфреске подобных ограничение нет.

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

http://www.directum.ru/315494.aspx

Что то в тупик мы заходим, надеюсь автор топика вернувшись из отпуска найдет среди кучи сообщений те, что адресовались ему. Мне интересно знать ответы. А теперь вернемся к редактору схем :)

Почему то так сложилось (видимо из за того что ИТ молодая отрасль), что бизнес думает , что с помощью компьютера возможно все. И все бизнес-аналитики кидаются красивыми фразами "надо смотреть с точки зрения бизнеса", "заказчику надо так и никак иначе". На мой взгляд отсюда и высокая провальность ИТ проектов, каждый смотрит со своей точки. Когда вы идете к строителям за постройкой нового офиса, вы тоже будете смотреть с точки зрения бизнеса? Я думаю вы все же учитываете законы физики, и ограничения, накладываемые текущими технологиями. Понятно, что со временем мы все дальше и дальше отодвигаем эти ограничения, но надо всегда понимать и помнить про них, чтобы эффективно работать. Это своего рода правила игры.

Возможно у меня не получается адекватно донести суть обсуждаемой ошибки, но я также вижу, что никто не старается её понять. Говоря: "у заказчика же есть в данный момент такие процессы", вы опять забываете, что перешли из виртуальной среды в физический мир, где такая ситуация не возможна в силу других правил игры (между людьми скорее всего перемещается один документ).

И кстати все равно DIRECTUM поддерживает реализацию данных процессов. Просто при переходе от логической схемы BPMN к ТМ в редакторе, картинка меняется, дабы учесть ограничения накладываемые виртуальной средой. Вспомните теорию баз данных. При переходе от логической схемы к физической практически всегда появляются новые таблицы. Схема становится другой, более громоздкой. Не буду снова занудствовать, говоря почему так происходит мою мысль вы наверно уже поняли.

Александр, смотрю Вы меня дефалтно причислили к бизнес-аналитикам и представителям Заказчика 8DD

Уверяю Вас, это совсем не так - я исключительно производственник, как разработчик знаю DIRECTUM с версии 3.2 и когда-то я полностью разделял Ваши взгляды. Кстати утрированно можно сравнить с позицией молодого сисадмина, который считает, что он знает как правильно все должно работать, а остальные вместе с генеральным глупые и ничего не понимают, и он так снисходительно заседает у себя в серверной с чаем.

Итого, по сути, что Вы говорите, что эта проверка - физическая необходимость (сравнивая с законами физики и теорией построения РБД), а я - что это архитектурный косяк проектировщиков системы (апеллируя к тому, что по идеологии СЭД должна удовлетворять потребность бизнеса). Александр, я правильно все собрал?

Если все верно - остается только ждать специалистов вендора (если придется, готов даже теорию автоматов и алгоритмов вспомнить) :)

Надеюсь ваши проблемы решаться :)

А мне все же интересно дождаться комментариев Андрея, которые раскроют технический аспект вопроса.

p.s. наверно мне так и не удалось обозначить свою позицию, раз утрировано она похожа на молодго админа, я считаю, что истина посередине, и надо двигаться навстречу. Увы, за мою, пусть пока скромную практику, я чаще видел столкновение двух крайностей.

Александр, я тоже очень надеюсь! Помню как было тяжело объяснить Заказчику, что его БП (которые мы же наанализировали :) ) слишком тяжелы для системы (т.к. кроме того, что их тяжело проектировать они еще долго выбирались сотрудниками, а они начинают тыкать мышой, система пишет что sbrte не отвечает и пипец), что после перехода на новую версию все будет хорошо. Это еще с 4.6.1 на 4.7, в которой в её первом билде(!) обещали исправить ситуацию с сохранением ТМов. Ответы СД типа "разбейте процессы на части", "упростите его" итд и эта тема - для меня как красная тряпка для быка 8D

Тогда не буду ей махать :)

Я как то проектировал ТМ, тоже постепенно уперлись в критическое количество блоков, после которого время сохранения начинало расти по експоненьте. Я тогда сделал спец. блок условие, который позволил убрать громоздкие конструкции из стандартных блоков условий, помогло, но не надолго. Пришлось "красной тряпкой" воспользоваться.

Позволю себе высказать свое мнение на счет имеющихся ограничений в редакторе маршрутов (если оффтоп, то прошу прощения).

Во первых, смысл существования любой компании, это удовлетворение потребностей потребителя, а не их ограничение. Предлагаю эту мысль принять как аксиому и не спускаться в дебри обсуждения ее истины.

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

В третьих, наличие у DIRECTUM этого ограничения не означает, что в мире алгоритмов и программирования существует такое же реальное ограничение, с которым никак не справиться в виду непоколебимости основ мироздания. Один из ранее приведенных примеров про альфреску это наглядно доказывает.

В четвертых, если использовать один цикл и несколько входов в него, это позволяет менять только один цикл в ТМ, когда меняется физическая процедура бизнес процесса, а не 2, 3 или 5 (как в случае с существующим ограничением).

Из текущей ситуации со своей позиции вижу два выхода:

1. Существующее ограничение должно быть обосновано не в рамках одной-двух голов, а для клиентов, которые покупают у нас ПО. Т.е. необходимо составить неопровержимую логическую линию, которая показала бы необходимость этого ограничения и превосходство перед его отсутствием для клиента.

2. Должна быть изучена потребность заказчиков. Должен быть принят факт, что существующее ограничение является помехой. Ограничение должно быть устранено.

Поскольку первое опровергнуто выше изложенными доводами, то оно в моем понимании может существовать только как архитектурная ошибка или как домысл, принимаемый за реальность.

Исходя их этой мысли, считаю, что необходимо изучить существующую несколько лет (!!!!) потребность и удовлетворить ее.

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

Кто-нибудь знает пример такого маршрута, где несколько входов в цикл будут представлять неопределенность в ходе маршрута?

Коллеги, простой эксперимент.

Ниже "вообще неправильная" схема. Редактор говорит, что ошибок нет.

Создам еще более глупую схему, в которой можно превратить выполнение задачи в кашу (картинка ниже). Билдер говорит, что ошибок нет:

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

Предполагаю, что билдер считает любое условие неопределенностью, в то время, как условия и задаются для создания определенноестей и уточнений.

В последнем примере (на последней картинке), считаю, что билдер не прав.

Ну что же, коллеги, смотрю что мы все же вышли к одному однозначному направлению комментариев!  С нетерпением ждем вендора 

На самом деле здесь обсуждаемая проблема уже неоднократно оформлялась в виде замечаний к разным версиям и это результатов не принесло (и даже видел тут на форуме сотрудника Заказчика, который особенно пострадал от этого, но пока он похоже на эту тему не наткнулся 8) ) .. возможно сейчас это обсуждение приблизит исправление сложившейся ситуации! 

Итак, поехали

1. Проверка схемы на корректность и расстановка блоков начала цикла (ExecutedBlocks) нужна для корректной работы Workflow. Причем самое страшное, что там может произойти, это не ошибка выполнения задачи, а уход обработки по неправильным веткам. Почему реализован такой "странный" механизм, я сейчас сказать не могу. Предлагаю написать в раздел "идеи" о том, что Workflow должна просто обрабатывать блоки по стрелочкам, а не пытаться делать что-то хитрое. Идею обязательно рассмотрят при отборе работ на следующую версию DIRECTUM. Быстрее это сделать, к сожалению, никак нельзя.
2. Вообще, у любой системы разработки огромное количество ограничений. И просто перегонять любую "хотелку" заказчика в однозначную реализацию не получится. Рано или поздно вылезут проблемы. В любой системе (будь то Documentum, DIRECTUM, Docsvision или Alfresco). Да, где-то ограничения вылазят раньше, гдето позже, но они есть везде. Так же и со схемами ТМ. Причем пути оптимизации хорошо известны: упрощение схемы с сохранением эквивалентности или вынесение части логики вовне (в прикладные блоки, подзадачи и т.д.).
3. Сообщения в стиле "все плохо" в материале о том, что сделали лучше, я вообще не понимаю. Было плохо. Стало сильно лучше. И?.. Причем на момент реализации оптимизации "летали" все ТМ, бывшие на тот момент. Сейчас есть ровно один ТМ, который тормозит.
4. По этому самому проблемному ТМ: ускорим (пока видится, что полный процесс сохранения со всеми проверками займет порядка 10 минут и будет вписываться по памяти в 1 Гб). Кроме того, сделаем возможность сохранения схемы с отключением провекрки на корректность. Постараемся выпустить это в ближайшем обновлении.

Андрей, с возвращением! Если я правильно понимаю, в данном случае Вы являетесь представителем разработчиков вендора, и Вас такая работа WF нисколько не смущает? То есть это нормальная работа и Вы отличный аргумент 

Вообще, у любой системы разработки огромное количество ограничений. .

Замечательный и достойный подход 

Мы сейчас говорим с Вами о конкретной проблеме платформы (не о "хотелке" заказчика) и на мой взгляд достаточно важной и серьезной. Кстати этого ограничения в приведенных Вами системах НЕТ. И мне кажется, что это должно исходить не идеей (какая же это ИДЕЯ - имхо налицо корявая реализация основного функционала СЭД) от нас, внедренцев, тем более не от представителей Заказчика, а от Вас, разработчиков СЭД, как считаете?

Давайте рассмотрим ситуацию, оторванную от СЭД. Предположим, что мне надо написать некую систему на ООП. Я выбираю .NET или Java, как наиболее продвинутые в этом плане платформы. И вдруг оказывается, что там нельзя из конструктора вызвать виртуальный метод. Это же просто кошмар какой-то: базовая концепция ООП, которая у других конкурентов (например, Embarcadero) всю жизнь работала, здесь не работает. Бред! "Налицо корявая реализация основного функционала ООП". Срочно вызываем на допрос представителей вендоров (Microsoft и Oracle), чтобы узнать, как они докатились до такой жизни. Смешно?

Во-вторых, это ограничение легко обходится без особых трудозатрат со стороны разработчика (через статический полиморфизм) по крайней мере в C++, и более того, этому есть четкое и логичное объяснение (принцип в реализации наследования в C++: при создании объекта конструкторы в иерархии вызываются от базового класса к самому последнему унаследованному.)

Андрей, объяснением ситуации может быть только логическое обоснование данного ограничения ("ограничения есть везде" - ну никак не логическое, согласитесь) или признание факта неверного решения при проектировании системы и, как следствия, регистрацией дефекта системы, а не идеи. На самом деле посмотрят конкуренты (или потенциальный Заказчик) на наши идеи - например "Корректная интеграция с Active Directory (LDAP каталогами)" и подумает, ничего себе ИДЕИ в DIRECTUM, у ЗОЛОТОГО партнера Microsoft интеграция с АД работает через раз (на протяжении 4х лет), и они исправление ситуации называют ИДЕЕЙ. Такая идея - давайте баги исправлять! Ну стыд просто 8\ (в первую очередь стыдно мне когда такое вылазит у Заказчика).

Андрей, ну реально ни о чем. просто сотрясение воздуха. 

Мне нечего добавить, кроме "объяснением ситуации может быть только логическое обоснование данного ограничения ("ограничения есть везде" - ну никак не логическое, согласитесь) или признание факта неверного решения при проектировании системы и, как следствия, регистрацией дефекта системы".

Я все еще не вижу смысла в псевдоаргументах "так у всех", так у "ООО Рога и копыта", которые к обсуждаемом проблематике никакого отношения не имеют. Вы считаете, чем больше Вы ограничений левых в мире найдете, тем сильнее Ваша позиция? Типа "отправь смс 'не лох' на номер 4343. Чем больше смс, тем больше ты не лох!!"  Я написал четкое объяснение, а Вы продолжаете свои писульки. Ну да ладно, нашу однонаправленную дискуссию на этом закончим, главное, чтобы все были здоровы! :)
А по поводу интеграции с AD - ну смешно слышать от разработчика 100% windows-ориентированной системы. На самом деле не смешно, а страшно 

и кстати, лично в моей практике за все время был 1 клиент с раб. группами, и 1 с NetWare и всё, все остальные с доменами Windows 8)

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

Единственное что я никак не могу понять, так это того, чего вы добиваетесь, публикуя все свое недовольство в комментариях к этому материалу. Чтобы мы перестали улучшать систему? Или чтобы мы перестали сообщать о том, что улучшили?

зато вы внимательно очень читаете. " регистрацией дефекта системы"

На самом деле я написал свое мнение, вы же вступили в диалог с флагом "так у всех". Я же не просто публикую свое недовольство, а оспариваю ваше утверждения типа "И это совершенно нормально" и что это просто " "хотелка" заказчика". Андрей, вы похоже совсем не читаете посты, зато знаете много случаев ПО с ограничениями :)

Раньше ТМ сохранялся достаточно быстро, после внесения ряда изменений стал сохраняться минут по 15-20, после сегодняшнего добавления в схему нескольких блоков сценариев, уведомлений и OR (причем включив их в текущую цепочку работ, без появления новых глобальных ветвлений) ТМ при сохранении сохранятеся.. а вот не знаю сколько, с 11 утра и до текущего момента еще не сохранился (16:15). Версия системы 4.6, в схеме процесса было 157 блоков до обновления, добавлено еще примерно 10.

В связи с чем вопрос:

Есть ли рекомендации по настройке схем процессов, соблюдая которые можно избежать длительной проверки при сохранении ТМ-а? Или наоборот, некие "вредные советы"?

P.S.: Из обсуждения выше понравились примеры, приведенные Димой Абрамовым; мне тоже не совсем понятно какие такие плохие цикличности проверяются при сохранении схемы процесса.

Коллеги, кто знает ответ? С какого-то момента после добавления нескольких блоков (кол-во превысило 100) при сохранении ТМ стал появляться вопрос о проверке схемы: "Выполнить проверку схемы?" с вариантами "Выполнить проверку" и "не выполнять проверку Схема будет помечена как некорректная". Сама проверка проходит быстро, результат проверки "схема не содержит ошибок". Вопрос всё же ЗА ЧТО? (ранее такого диалога не было при нажатии на кнопку ленты "Сохранить маршрут"). Версия 5.0.

Константин, это как раз было добавлено в рамках описанных здесь оптимизаций. Система боится, что ваша схема будет проверяться долго, потому и спрашивает. На тот момент никаких достоверных и быстрых способов предсказать время проверки схемы не было (поэтому сделали перестраховку). Не знаю, как сейчас.