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

14 50

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

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

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

Первая же серьезная попытка оказалась вполне удачной - самая сложная схема проверялась меньше двух минут. Количественно это был прорыв, но качественно хотелось большего: не просто сильно оптимизировать процесс сохранения ТМ, а зарубить на корню даже малейшие признаки тормозов этом процессе. Поэтому работы были продолжены и, в конце концов, результат достигнут - самая сложная схема проверялась на корректность 6 секунд, остальные - еще меньше (от долей секунды до двух секунд на моем Core i3 - 3 GHz).

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

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

Быстрое сохранение схем ТМ появилось в DIRECTUM 4.8 с самого первого билда и в DIRECTUM 4.7 начиная с IS-Builder 7.8.3.1521.

14
Авторизуйтесь, чтобы оценить материал.
2
Михаил Сергеев

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

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

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

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

 
Андрей Куров

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

Александр Гуртяков

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

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

Андрей Шилов

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

Андрей Подкин

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

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

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

Андрей Шилов

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

Михаил Сергеев

По пунктам:

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

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

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

6) 

 

Написать ТМ, который гарантировано будет проверяться слишком долго

Написать можно. Хуже, когда он уже написан. И, кстати, блоков там не больше 150. Точнее сказать не могу, вы же теперь их не перенумеровываете...
Евгений Иванов

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

Андрей Подкин

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

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

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

Евгений Иванов

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

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

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

Михаил Сергеев
Но чем плоха быстрая проверка маршрута

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

 

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

Мы благополучно отключали, и вручную устанавливали признак корректности. С недавних пор эту возможность отобрали.
Андрей Шилов

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

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

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

Александр Гуртяков

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

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

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

Андрей Шилов

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

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

Евгений Иванов

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

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

Евгений Иванов

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

Андрей Шилов

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

Евгений Иванов

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

Александр Гуртяков

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

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

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

Евгений Иванов

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

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

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

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

"Являясь реализацией бизнес-ориентированного 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. Должна быть изучена потребность заказчиков. Должен быть принят факт, что существующее ограничение является помехой. Ограничение должно быть устранено.

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

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

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

Андрей Манаков
наличие двух входов в цикл - это потенциально, то место где может возникнуть неопределенность в последовательности выполнения блоков маршрута. Это равносильно некорректному  синтаксису в редакторе кода.
Ключевое слово здесь - "потенциально"! Все потенциальные ошибки практически в любом компиляторе/проверщике синтаксиса - определяются как Warning а не как Error! И в любом случае позволяет сохранить код (!) сколько бы warning'ов там не было.
 
Да и наличие двух входов в цикл не всегда 100% служит возможностью возникновения неопределенностей. Разработчик может создать ТМ даже и с несколькими входами в цикл, но 100% не ведущий ни к каким неопределенностям/ошибкам ни при каких обстоятельствах.
Но обсуждаемое ограничение заставит его (скрепя сердце) превратить любой подобный ТМ в тяжеловесного монстра...
 
Ответственность за какие-либо неполадки при работе ТМ однозначно будет на разработчике этого ТМ. Поэтому и решение, использовать "в работе" такие ТМ или нет, лежит полностью на совести разработчика, а не на алгоритме проверки корректности схемы.
Проверка должна лишь предоставлять информацию, а не принимать решения за разработчика.
Андрей Куров

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

Дмитрий Абрамов

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

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

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

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

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

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

Евгений Иванов

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

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

Андрей Подкин

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

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

 

Михаил Сергеев
Стало сильно лучше
Стало лучше, именно без "сильно". Это количественное достижение.
 
Сейчас есть ровно один ТМ

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

Вот за это отдельное спасибо. Давно просили вернуть, но вы долго сопротивлялись...
 
В любой системе (будь то Documentum, DIRECTUM, Docsvision или Alfresco)

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

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

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

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

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

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

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

Андрей, ну не смешно, не нужно съезжать на левые примеры, мы говорим о СЭД, в частности DIRECTUM, и меня волнует в данный момент ограничения, связанные с ней.

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

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

И еще, Евгений, ответьте, пожалуйста на вопрос: сколько маршрутов у вас сейчас (на указанных в посте версиях системы) тормозит или вылетает с нехваткой памяти?
Если Вы имеете ввиду тормозит при сохранении? К сожалению те проекты, где реально тормозит (20 мин сохранения маршрута на сервере с 16Гб памяти огорчали, помню, безумно на 4.6.1) и можно было бы проверить оптимизацию - самый поздний билд IS-Builder 7.8.3.1048, у последних клиентов таких больших процессов нет. Кстати у больших организаций многоблочных процессов достаточно много в процентном соотношении (я к тому, что писал выше про долгое сохранение не на основании одного маршрута).
Дмитрий Абрамов
Нет. Признак корректности необходимо устанавливать вручную.
Андрей, подскажите еще такой момент, пожалуйста.
Это признак можно будет изменить в карточке записи справочника Типовые маршруты или для этого потребуется update реквизита в БД (или внесение изменений в XML)?
Андрей Подкин
Во-вторых, это ограничение легко обходится без особых трудозатрат со стороны разработчика (через статический полиморфизм) по крайней мере в C++, и более того, этому есть четкое и логичное объяснение (принцип в реализации наследования в C++: при создании объекта конструкторы в иерархии вызываются от базового класса к самому последнему унаследованному.)
Вот этого я и ждал wink
Вы предложили механизм удобный системе взамен механизму, удобному мне.
 
ничего себе ИДЕИ в DIRECTUM
А кто сказал, что идеи не могут быть такими? Кого-то совершенно не напрягают большие ТМ или интеграция с AD (им это просто не надо), зато подавай "рюшечки" типа раскраски и подсветки.
И это совершенно нормально. Например, мне как клиенту компаний Dell и Canonical тоже не нравятся некоторые идеи на их сайтах (почему этого нет как данности уже лет 5-6???). Но я знаю, что являюсь далеко не единственным клиентам и признаю, что мои первоочередные потребности для кого-то могут быть совсем не важны.
 
 
Это признак можно будет изменить в карточке записи справочника Типовые маршруты или для этого потребуется update реквизита в БД (или внесение изменений в XML)?
Этот реквизит не вынесен на карточку. Но его можно поменять из ISBL-кода, например, из сценария. Кстати, некорректные маршруты и сейчас нормально сохраняются с этим признаком. Т.е. то, что мы делаем сейчас - это возможность не ждать проверки корректности на большом/сложном ТМ.
Евгений Иванов

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

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

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

Евгений Иванов

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

Андрей Подкин

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

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

Евгений Иванов

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

Евгений Иванов

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

Артем Сунцов

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

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

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

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

Андрей Подкин
Есть ли рекомендации по настройке схем процессов, соблюдая которые можно избежать длительной проверки при сохранении ТМ-а? Или наоборот, некие "вредные советы"?
 
Самое простое - это минимизировать количество циклов (особенно вложенных).
Константин Тарасов

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

Андрей Подкин

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

Авторизуйтесь, чтобы написать комментарий