Pull to refresh

Comments 45

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

А вот проблемы с параллельностью это да, это ад.
Тут, наверное, резоннее мне было бы показать, как можно сделать. Я бы разделил каждую Activity на три части: View, State, Execution. View показывается в дизайнере, её задача: создать State по умолчанию. State — это текущее состояние Activity (то есть кубика), он и только он сохраняется в базу. Execution — это Singleton уровня Instance или приложения — не знаю, как бы я делал, но самое главное, что он бы не сохранялся в базу. И его схема работы была бы следующей: на вход State, на выходе State + еще опции (что-то вроде «эта activity завершилась» и т. д.). Как Вам такая реализация? Здесь сложнее сделать ошибку с сохранением.

Про сохранение — я привел в пример delay activity, когда ждать следует 0 секунд. Зачем здесь сохраняться?
Про сохранение — я привел в пример delay activity, когда ждать следует 0 секунд. Зачем здесь сохраняться?

Вы сейчас хотите сделать так, что бы Delay Activity стал очень умным. DelayActivity должен сохранить состояние процесса, выгрузить его из памяти и при необходимости «поднять» его и снова запустить. Delay Activity не надо делать очень умным, как и любой блок вашего WorkFlow. Сам WorkFlow должен выбирать куда идти и что делать. Если вам надо попасть в Delay Activity, значит вам надо сохранить и заморозить поток. Какой срок, это исключительно ваше дело, но этот блок должен делать именно то, что он сейчас делает.
Это усложняет работу с ним манагеру, который конструирует. Он мог родить туда Delay, позже оптимизировали и убрали её. Перерисовывать удаляя — не всегда хорошо, а вдруг опыт покажет, что надо вернуть?
Манагер не должен работать с этим делом. Аналитик какой нить, да, возможно.

Но опять таки, оставлять активити, лишь потому что «а вдруг», есть очень плохой путь.
Я Вас не понял. Delay Activity — это пауза на N секунд. Просто пауза, если мы говорим про загрузку, то тут должны быть какие-нибудь Save/Load Activity (их нет, кстати). У нас пауза была для каждого WCF соединения, чтобы вызвать его еще раз, если прошлый вызов не заработал. А если он сработал — то не ждем. Вот в таком алгоритме, по моему мнению, нулевое ожидание следует понимать как команду NOP.
Видимо у нас с Вами разное восприятие понятия пауза в каком либо рабочем потоке. :) Я предполагаю, что это не просто пауза, а выгрузка всего процесса из памяти с последующей загрузкой. И как раз таки не Delay должен решать, нужно ли делать паузу (а следовательно и выгрузку — загрузку) или нет. Да и управлять тем, делать ли Unload при простое или нет, можно путем реализации UnloadOnIdle в, уже упомянутом вами, WorkflowPersistenceService.
И как раз таки не Delay должен решать, нужно ли делать паузу (а следовательно и выгрузку — загрузку) или нет.
Имею ввиду должны ли мы попасть в Delay Activity или нет. И если попали, то дальше уже рулить тем, как мы ведем себя в ожидании путем реализации UnloadOnIdle.
Тут всё зависит от того, насколько система должна быть стабильной, и насколько много через неё проходит задач. UnloadOnIdle всегда выставляется в true, иначе наши Activity всегда будут в памяти, если не вызывать периодически метод Unload.

То есть, если UnloadOnIdle == true, то будут вот такие особенности:
1. В памяти больше Activity, а это падение производительности (см. график в статье) для остальных + заблокировано большее количество Workflow Instance, чем следует. Кстати, это тоже падение производительности. И не забываем про блокировку, ограниченную во времени, то есть мы не может совсем долго тянуть с Unload.
2. Нам потребуется вызывать метод Unload самостоятельно. На деле это очень и очень плохая идея, так как сделан он крайне криво. Дело в том, что если Workflow Instance не находится в памяти, то он сначала будет Load, а потом — Unload. Двойной Load для Instance приводит к порче памяти, а такое возможно, если загрузка идет в нескольких потоках (еще одна проблема Microsoft Workflow, кстати). Более того, если Workflow Instance удален (то есть как-то остановился, не важно даже как), в памяти его нет, а мы сделали Unload, то сначала произойдет Load, а, раз Workflow Instance отсутствует в памяти и в базе, мы получаем исключение на ровном месте. А дальше, с малой долей вероятности (я не смог отследить правильную последовательность действий), мы еще и получим ломаный Workflow Instance в памяти, который не может быть выгружен, и из-за которого не будет останавливаться Workflow Runtime.

Всё это мы, конечно, не сразу получали, а постепенно, экспериментальным путем. В общем, я бы не советовал вручную рулить загрузкой и выгрузкой.
State — это текущее состояние Activity (то есть кубика), он и только он сохраняется в базу.

Это и так сохраняется. Просто движок воркфлоу это сложная штука. И продолжая…

Execution — это Singleton уровня Instance или приложения — не знаю, как бы я делал, но самое главное, что он бы не сохранялся в базу.
Не совсем понял что вы имеете ввиду. А как же дополнительные данные о воркфлоу, такие как какой сейчас шаг, под кем был запущен, состояние общее, контекст выполнения? Эти вещи нужны движку воркфлоу. Их то куда деть?
Я Вас не понял… Изначально Activity — это то, что будет нарисовано в дизайнере + то, что будет выполняться + то, что будет сохраняться.

На тему сложной штуки — абсолютно нет, он скорее запутанный.

Я предлагал сохранять для каждой Activity не всё, а только State. Это не отменяет того, что, скорее всего, потребуется еще хранить сам алгоритм работы, параметры по умолчанию и т. д.
Сразу отмечу, что пост я писал не для того, чтобы показать, как всё плохо. Нет. Он создан для того, чтобы разработчики уже более-менее знали, как бороться с этими особенностями. Раз я видел ошибки в проекте, то логично, что есть (и будут) другие проекты, где они тоже появятся. Как Вы видите, у меня на каждую недоработку есть решение.
Слишком много заблуждений в одной статье. Видно что автор с технологией не знаком.

Workflow Foundation никогда не был инструментом для аналитиков, даже дизайнера wf вне VS никогда не было. А уж удобного для людей, а не программистов, и подавно.

WF используется в нескольких продуктах microsoft, таких как sharepoint и dynamics crm. собственно первый wf появился как раз из-за sharepoint, а wf4 из-за dynamics. Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который можно нужно использовать и в своих приложениях. Самое главное что во всех этих серверах используется свой workflow host, в котором нет описанных недостатков.

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

Самое главное — workflow хорошо работает когда много параллельно ожидающих процессов. Например есть сценарий рассылки для новых клиентов, где каждому отправляется по одному письму в неделю. Реализация такого робота в коде получается громоздкой, а в wf — элементарной.
Workflow 3.0 можно было использовать для создания дизайна все MS VS. Причем даже не линкуясь на сборки MS VS. Я могу код быстренько сделать и продемонстрировать, если это требуется. Более того, если разрешить кидать на холст (для рисования) только свои Activity + справа сделать вывод свойств, то получится в более-менее нормальный дизайнер. Так что Вы не правы.

WF 3.0 идет как отдельная библиотека в .Net 3.0: %systemdrive%:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation. То, что он появился изначально в другой технологии, не так важно начиная уже с .Net 3.0, так как библиотеки Workflow не линкуются.

Про SharePoint 2013 — я не про него писал, а про то, какие интересные моменты от использования Workflow в своих приложения. Так-то да, нам следует взять объект Workflow Runtime и все запуски делать через него.

На тему параллельной работы: блокировка объектов происходит функцией RecoverInstanceLocks (я вставил выдержку из кода ниже). Это код WF 4. В предыдущей версии стиль тот же, просто нет top 1000. Как Вы понимаете, всё хорошо только в случае, если у нас все задачи очень быстрые. Более того, через две минуты придет новая порция данных, даже если эти еще не обработанные. Что в паре с нелинейной асимптотикой производительности дает плохой результат.

RecoverInstanceLocks
	insert into [RunnableInstancesTable] ([SurrogateInstanceId], [WorkflowHostType], [ServiceDeploymentId], [RunnableTime], [SurrogateIdentityId])
		select top (1000) instances.[SurrogateInstanceId], instances.[WorkflowHostType], instances.[ServiceDeploymentId], @now, instances.[SurrogateIdentityId]
		from [LockOwnersTable] lockOwners with (readpast) inner loop join
			 [InstancesTable] instances with (readpast)
				on instances.[SurrogateLockOwnerId] = lockOwners.[SurrogateLockOwnerId]
			where 
				lockOwners.[LockExpiration] <= @now and
				instances.[IsInitialized] = 1 and
				instances.[IsSuspended] = 0



Я видел rehosting дизайнера, но для непрограммистов это неюзабельно. в sharepoint есть свой дизайнер, который в разы проще, и то люди с трудом им пользуются, в crm аналогично. Для sharepoint есть еще фишка — создание workflow в visio, но в визио можно сделать только форму, а логику надо все равно делать в дизайнере sharepoint.
Вы правы, стандартный дизайнер сложен для понимания. Он, кстати, используется в TFS, чтобы создавать сценарий билда. Я пока только один раз услышал хвалебный отзыв о этой фиче. Так что тут я с Вами полностью согласен.
Если хочешь использовать workflow, то cтавь workflow manager, не изобретай велосипеды.
Да, Workflow Manager может быть полезен.

Однако я не нашёл способа, как, например, избавиться от проблемы некорректной загрузки (то есть загрузки по 1000 элементов за раз). У вас была такая задача?
Не было, я руками workflow делал ровно один раз, но там не было нагрузки, чтобы это стало проблемой. С момента появления wfm использую только его. Процессы ессесно не realtime, точности достаточно в одну минуту, зато 10к всего процессов (из которых максимум 100 работают одновременно) выдерживает легко.
Да, такое у нас тоже работало. У нас вот что было: некоторые Activity запускались раз в сутки (проверили и спят дальше). И, соответственно, всего около 20 000 — 40 000 рабочих процессов. И около 5 000 — 8 000 имели ежедневную активность, но были размазаны более-менее по суткам. И всё было хорошо до тех пор, пока платформу не остановили на выходных на сутки где-то. Дальше ежедневные ребята резко начали работать. Результат я описал.
Автор — мой коллега, статья по-видимому родилась из шестимесячного упражнения по рефакторингу workflow в крупной SaaS системе (2-й по размеру игрок legal рынка в штатах). Так что знакомство у комманды с предметом было весьма близкое…

С парой вещей я соглашусь:

— workflow (в теории) скалится хорошо, если (даже не так: ЕСЛИ) все activities очень легкие (=короткие) и сами по себе скалятся тоже. Если нагородить тяжелых активити, которые грузят базу тяжелыми транзакциями, делают ощутимые вычисления, используют триггера и тяжелые UDF-ы, блокируют друг друга или вообще любят что-то погонять в синхронном режиме — все будет плохо. Workflow тут вообще-то не при чем, просто из-за длительности транзакций играет конструктивное ограничение, про которое не все в курсе. Наверное, общая рекомендация тут такая: если есть тяжелые активности, делайте их асинхронными. Да, магии не будет.

— в нормальной ситуации аналитики, конечно, сами workflow не пилят, это вотчина devops / solutions. Другое дело что devops часто сами выступают в роли аналитиков (т.е. сами говорят с заказчиками и реализуют изменения) и крутят эти самые workflow не особенно думая о том, что творится внутри. Специфика конкретного клиента в том, что там был сделан встроенный workflow designer и это еще усугубило проблему, ибо рисованием workflow вообще занялись не особо технические люди…

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

Disclaimer: это не мой проект, я в менеджменте компании, всех деталей могу не знать. Если где соврал — то по чистосердечному заблуждению… Игорю спасибо за статью!
Слишком много заблуждений в одной статье. Видно что автор с технологией не знаком.


Поменьше понтов и трёпа, юноша! Во-первых, статья явно изобилует техническими фактами, чтобы говорить, что «автор не знаком» — знаком и ещё как!
Во-вторых, «заблуждения» — только в вашем видении 2014-го года и ТОЛЬКО применимо к новейшим продуктам. Касательно даже WF 4.0 это не заблуждения, а ФАКТЫ. Извольте не бросаться словами, не имея на то причин и не перевирать оригинальный смысл статьи. В ней конкретно сказано, с какими продуктами работал автор и конкретные проблемы. Хотите покритиковать? Цитируйте, приводите контраргументы применительно именно к этим версиям. А рассуждать «микрософт что-то там написала ещё лучше, ещё шелковистее» — не надо, это работа отдела маркетинга.

Workflow Foundation никогда не был инструментом...


Зачем НАМ это всё объяснять? Пишите прямо в спортлото Микрософту! Пусть ОНИ в своём маркетоидом хламе разберутся и БОЛЬШИМИ КРАСНЫМИ БУКВАМИ напишут ваши слова, достойные гранита: «Workflow Foundation никогда не был инструментом для аналитиков, даже дизайнера wf вне VS никогда не было. А уж удобного для людей, а не программистов, и подавно.» Как только я это прочитаю на сайте микрософта, смело одену майку «микрософт рулез!».

workflow хорошо работает когда...


… и это тоже отошлите в микрософт — чтобы при покупке, клиенты не делали унылое лицо «почему у нас плохо работает» — оказывается, WF работает только «КОГДА»! Если ваше «когда» не совпадает с «когда» микрософта, увы — вам этот продукт не подходит. Хорошо бы микрософт описала ВСЕ «КОГДА», когда их продукт не справляется с задачами, которые КАЗАЛОСЬ БЫ должны были решаться именно инструментом, гордо называемым «workflow»!
В политике МС нельзя ругать свои продукты и технологии. Поэтому никогда такое на сайте не прочитаете. Но можно еще включать мозг и смотреть как сам МС применяет технологии. Ни разу не обращали внимания, что только те технологии, которые сам МС применяет в своих продуктах, оказываются хорошего качества? На примере того же workflow, который применялся только в sharepoint, только в 2011 появился в crm, в 2013 в wfm и powershell. Причем везде используется кастомный хост и кастомный дизайнер. Это не наводит на мысли что глупо использовать стандартный workflowappliation и стандартные сервисы? Странно если не наводит.
В том и дело, что на момент максимального раздутия рекламного пузыря, ничего нельзя понять! Фирма презентует продукт ДЛЯ ПРОДАЖИ, редко кто пишет про догфудинг. Тот же Word — нигде не пишут, что «наша секретарша в нём служебки пишет!» :)
Вот вышел WF — что людям делать? Пытать Гейтса «где он у вас заюзан»? Да продукт только вышел, считай нигде! Поэтому люди читают рекламу, статьи, сравнивают со своими задачами — глупо их винить в том, что они читают (sic!) «инструкцию к применению». Раз написали workflow — будьте добры, вот мой рабочий процесс, применяйте!
И вот автор и применил — не вижу ничего криминального в том, что человек описал все грабли, на которые наступил благодаря «проталкиванию» продукта микрософтом.

Вот что я знаю, что Delphi писалась на Delphi — этому продукту я доверяю.

Это не наводит на мысли что...


Нет, не наводит. Есть продукт, есть ниша его применения. Если продукт ей не соответствует, то не надо рассыпаться советами про «кастомный дизайнер» — это уже ФЭЙЛ продукта. «Костыли» всегда можно написать, наша задача — с самого начала выбрать(написать) продукт, требующий минимума подпорок и уж точно без таймбомб! Остаётся только посочувствовать ребятам, которые потратили время на никчемный, расхваленный продукт. СЕЙЧАС он МОЖЕТ БЫТЬ и созрел, но кто вернёт время и деньги за прошлые проблемы? Да и знаете… у джентельменов есть такое слово — «репутация». Раз обгадил — будешь всю жизнь оттираться, мракософту не привыкать.
Вот вышел WF — что людям делать? Пытать Гейтса «где он у вас заюзан»?

Именно. Если технология не прошла догфудинг в МС, то скорее всего в первой версии будет неюзабельна.

И вот автор и применил — не вижу ничего криминального в том, что человек описал все грабли, на которые наступил благодаря «проталкиванию» продукта микрософтом.

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


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


Мы обращались в Support Microsoft по поводу этой технологии. Ответ был, примерно, таким: «Да, эта технология забагована, так что, скорее всего, вы нарвались на один из багов ...»

Кстати, а можно Вас попросить аргументировать фразу «что автор использует неверный подход»? Задача такая: у нас есть около 1000 Workflow Instance и, допустим, 5 запущенных процессов. Ожидания: все процессы распределят нагрузку равномерно. Если запустить только один процесс, то время обработки займет час. Вопрос: как правильно использовать технологию MS Workflow таким образом, чтобы время обработки сократилось раз в пять, примерно (ну то есть чтобы не первый процесс забрал все задачи, а они бы распределились равномерно). Каждый процесс запущен на отдельном сервере.
Для начала поставить Worflow manager и запустить все на нем. Он умеет параллелить процессы между нодами и еще дает отказоустойчивость.
автор использует неверный подход… МС не озаботились дать верный подход


Один я тут вижу логическую несуразность?
Если все изучение начинается и заканчивается маркетинговыми материалами, то да, фраза кажется несуразной.
Но я как-то привык читать код и анализировать готовые решения ДО того, как кидаться применять технологию.

Например до применения ASP.NET MVC еще CTP версии, по которой не было никаких реальных примеров, я изучил ВСЕ видео и дважды просмотрел код рефлектором чтобы понимать чем мне грозит.
я изучил ВСЕ видео

Нуждается в доказательстве. Как Вы проверили, что в интернете отсутствуют другие видео? Или Вы смотрели только официальные видео?

дважды просмотрел код рефлектором

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

Если все изучение начинается и заканчивается маркетинговыми материалами

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

Но я как-то привык читать код и анализировать готовые решения ДО того, как кидаться применять технологию.

А по какой метрике Вы определяете, что Ваши знания о технологии дошли до необходимого уровня? Если Вы будете читать вообще весь код всех используемых библиотек, то у Вас уйдет около 5-10% времени, которое потратили разработчики (пруф). Ну то есть если Вы захотите выбирать между пятью технологиями, то Вам можно просто её сделать с нуля за сопоставимое время

В общем, хотелось бы аргументации.
Видео на тот момент было от силы десятка два роликов от 2 до 20 минут. Напомню что CTP версия, еще ничего не было.
Код смотрел рефлектором, для ASP.NET MVC первой версии было его совсем немного, сумарно пару тыщ LOC, достойных внимания. Ушло на это примерно неделя.

Метрика достаточности знаний субъективная — когда очко перестает играть от мысли применения технологии в реальном проекте. некоторые вещи МС я бы до сих пор не взялся в реальном проекте применить.

Выбора между пятью обычно нет, есть выбор использовать готовое или наструячить свое. В этом случае имеет смысл потратить на изучение, ибо даже если струячить свое, то можно многому научиться разбираясь как работает существующая технология.
Весь смех в том, что даже если «открыть рефлектором» Notepad, можно МЕСЯЦ медитировать над кодом и всё-равно ничего не понять (думаю, вы не опуститесь до детсада сравнивать интеллект разрабов?). Вывод компилятора — это далеко не тот объект, за который можно садиться. Да чо там, я даже за документированные исходники сяду — и то только и пойму, что из чего вызывается — КАК этот смешной «метод тыка» может что-то говорить о качестве?? Вы уверены, что эти 1000 классов оптимальны? Вы видели архитектуру в целом? Вы слышали ВСЕ варианты для реализации? Где описаны все допустимые use cases? Есть ли среди них ваш? Решён ли именно ваш case оптимальным образом? Какие вообще ставились задачи и насколько много времени было у разрабов, чтобы хорошо спроектировать код?
Во сколько вопросов! Я б не был таким оптимистичным, залазя в груду кода рефлектором — есть такие стены, где лоб лучше сразу поберечь.

И как доказательство сырости WF, ваши же слова: «Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который нужно использовать и в своих приложениях». Осталось дело за малым — тем пацанам из 2005-го прислать машину времени и дать sharepoint 2013 :)

Я не вижу вообще никаких причин в чём-то укорять автора — ребята — не медиумы, чтобы из ниоткуда выяснять, насколько хорош продукт: микрософт выкатила — значит «отвечает за базар», а люди просто следуют документации и пишут. ЭТО НОРМАЛЬНО. Ненормально — это писать всякую хрень, называть workflow и брать ещё за это деньги.
Notepad — нативное приложение, его рефлектором не откроешь. Но по исходникам вполне можно разобраться что к чему.
Для .NET код все проще, рефлектор очень помогает. Код шарика я именно рефлектором изучал, он дает на несколько порядков больше понимания, чем любая документация и гайды. ASP.NET MVC, особенно первых версий, очень простая вещь и нет проблем изучить как оно работает.

При чем тут качество я не понял. Нужно не абстрактное качество, а реализация конкретных сценариев.

И как доказательство сырости WF, ваши же слова: «Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который нужно использовать и в своих приложениях». Осталось дело за малым — тем пацанам из 2005-го прислать машину времени и дать sharepoint 2013 :)

Машины времени не существует, но это не означает что в 2013 году надо свой код писать так, как посоны из МС предполагали писать в 2005, не находите?

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

Для аналитика:
В случае прототипа можно остановиться на Visual Studio Express, в котором можно создать дизайн. Для реальной платформы корректнее всего потом создать свой дизайнер, чтобы избежать разного рода code-injection (так как if activity содержит, например, код для выполнения). Плюс стандартный дизайнер далеко не самый удобный. Самое главное — чтобы в конце получался строчка с xaml с бизнес-процессом.

Для пользователя:
По идее, он вообще не должен особо видеть, что работает внутри. Он должен четко знать, что на его действие А система реагирует действием Б. И всё. А уже как оно происходит не особо важно. Разве что заказчик должен знать, что процесс всегда можно поменять лично для него.
А в какой среде будет выполняться рабочий процесс? и как (через какое приложение) пользователь совершит действие A, которое как то должно повлиять на систему в которой работает бизнес процесс?
Здесь есть варианты, однако есть два основных:
1. Используйте класс Workflow Runtime, чтобы сообщать об Event'ах, запускать процессы и останавливать их
2. Можно хостить Workflow как web-сервис (более того, можно это делать на разных серверах). Тогда общение будет происходить через WCF

В целом, схема такая:
1. Запускаете рабочий процесс. Он работает, вызывает сервисы, посылает письма, ждет — в общем, что-то делает.
2. Если Вам требуется, иногда, ждать действий пользователя, то поддерживаете Event Model. Ну то есть идете дальше, если приходит этот самый Event.

Например, если у Вас web приложение, то event можно посылать в момент обработки пользовательского запроса. Дальше Workflow крутанется и как-нибудь отреагирует. Например, если требуется проверять, что пользователь правильно заполнил форму, можно использовать Workflow: оно сначала проверит, что всё более-менее правильно, потом отправит письма и т.д. Программист создает только отдельные кубики, аналитик их соединяет и настраивает.
Мы используем, но наша нагрузка пока низкая. Фактически у нас нет workflow как таковых, эта служба используется как запуск задач на ежедневной основе с некотрым load-balancing и fault tolerance и вроде это как-то работает.
К сожалению, пока не могу проголосовать за статью, но не выразить своё «плюсадин» не могу! :) Спасибо за то, что описали реальные проблемы продукта! В своё время чуть было не попали в это «болото workflowщины», благо уже тогда звенели тревожные звоночки — теперь даже явно видно какие.

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


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

Ну а если нагрузка начнет расти, Вы сможете модуль за модулем перенести на свою эффективную реализацию.


Остался вопрос, а зачем тогда нужен сам WF, если «всё своё» :)) Для лэйбла «best viewed with Workflow»?
А вариант «написать самому» вообще не рассматривается что ли? :)


Тут есть тонкий момент. Проект живет на Production около шести лет. Первый релиз делал не я, но, как мне стало понятно, алгоритм принятия решения был, примерно, таким: «О, я услышал на конференции про крутую тему — Workflow. На ней можно кастомизировать наши бизнес-процессы. Давай попробуем, как оно. Только быстро». Разработчик ответил — не вопрос. Он реализовал быстренько методы, быстренько доделал дизайнер и готово. И это было реально шустро. Более того, оно проработало несколько лет, причем Engine почти не претерпевал изменений.

Сейчас, если бы у меня стояла задача сделать то же самое, я бы не раздумывая сделал своё. Для меня это было бы и быстрее по срокам, и надежнее в плане работы. А вот если взять программистов, которые ни разу не делали ничего подобного (Enterprise проект, Вы понимаете, что там операции только web-база-web, никакого дикого параллелизма, всё просто, кроме маленьких соседних модулей, и это скорее исключение), то им лучше дать хоть что-то готовое. Тогда бы проект вышел бы в свет в более-менее разумный срок. Как MS сталкивалась с ошибками при разработке, так и пришлось бы этим разработчикам столкнуться.

Так что тут всё зависит от того, насколько команда имеет опыт разработки параллельных/распределенных задач. Если опыт есть — пусть пишут сами. Если опыта нет, но утвержденные (!) планы грандиозны — тогда пусть пишут сами. Если особых планов нет, просто хотелось бы побыстрее сделать маленький кусок, а далее, если пойдет, то еще доделать, то тут лучше взять готовое. Это, естественно, моё мнение.
Не-не, я не про ваш конкретно проект, мы же говорим вообще: «лучше работать с системой, от которой известно, что ожидать» — т.е. это общее утверждение, вот я и спросил, почему бы не написать что-то самим. Но за развёрнутый ответ спасибо. :) Так нередко и получается: дают legacy систему, а ты смазываешь подпорки. :)

Раз уж статья была упомянута в 2020м году — отвечу. Скажу сразу — отвечаю я про Workflow 4.0, в более ранней версии и правда местами какая-то хрень была. Но, раз уж статья претендует на рассказ о недостатках WF "в общем"...


Типичный пример из Workflow 3.0 — Вы подписались на Event с помощью лямбы/анонимного метода.

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


Если вам надо подписаться на событие — вам нужен диспетчер событий с персистентным состоянием (т.е. с доступом к БД). Далее надо сделать NativeActivity, которая создаст закладку (bookmark), и передаст диспетчеру идентификатор процесса вместе с идентификатором закладки. При наступлении события диспетчер должен разбудить процесс и возобновить его с места сохранённой закладки.


Ну или можно использовать что-то стандартное, где всё это уже реализовано, но когда я использовал WF — мне ничего стандартного не подошло, поэтому я уже не помню есть ли оно там вообще. Сейчас я в msdn не вижу ни одного наследника NativeActivity который бы умел так делать.


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

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


Ну и не забывайте про существование NoPersistScope.


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

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


Ждать события от внешнего сервиса — идея разумная, но ожидание всё равно вам потребуется, в качестве тайм-аута.


В предыдущей части я написал, как работает Persistence Service: он забирает всё из базы. [...] Решение: сделать свой обработчик Activity, переиспользовать Activity, cделать эмуляцию Ваших рабочих процессов. По факту Вам придется быстренько реализовать базовый компонент Workflow, который занимается стартом и остановкой Activity.

Уточнение: не стартом и остановкой, а засыпанием и пробуждением.

Sign up to leave a comment.

Articles