Программист
0,0
рейтинг
14 июля 2014 в 09:14

Разработка → Microsoft Workflow — антимаркетинг

.NET*
Привет, хабр.

Я думаю, многие из вас слышали о такой технологии — Microsoft Workflow. Она довольно неплохо раскручена, есть посты на хабре, есть книги на английском и на русском. Да и Microsoft публикует красивые картинки.

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

image

И далее бизнес-аналитик именно его и рисует. Программистам стоит лишь реализовать процедуры Accept, Reject и остальные похожие кубики. Круто, да?
Мне не особенно повезло в том, что я слышал об этой технологии только из книжек и из маркетинговых изданий. Ну и конечно из презентаций вида «Мы посмотрели на MS WF полгода назад, уже месяц немного используем — полет нормальный!». Я же работаю с продуктом, в котором Workflow внедрена уже 6 лет (сам я с ним работал всего пару лет), который имеет достаточно высокую нагрузку, а потому хотел бы показать основные подставы и засады этой библиотеки. Я надеюсь, пост поможет избежать тех же граблей, на которые наступали мы.


Как оно работает?

Идея крайне проста: программист создает кубики — Activity. Каждая Activity может иметь параметры. Например, можно создать RejectActivity cо свойством User. Чаще всего это будет означать, что Reject будет происходить для этого User'а. Каждая Activity, по сути, имеет внешнее представление (то есть то, как её увидит бизнес-аналитик) и реализацию. Кстати, здесь мы сразу получаем засаду #1: это один и тот же класс. Ну то есть наш красивый дизайнер должен линковаться на реализацию. Но это решается крайне просто с помощью IoC, потому назовем это лишь разминкой.
Когда бизнес-аналитик сделал дизайн (то есть нарисовал кучу activity, соединил их стрелочками), его можно сохранить в виде Xaml представления. Которое сможет загрузить Microsoft Workflow Runtime и начать выполнять.
На некоторых Activity можно сделать паузу (например, Delay Activity). В этом случае рабочее состояние сериализуется в базу. Ну и через определенное время (как мы сами указали) наш рабочий процесс опять проснется и пойдет дальше. Для сохранения нам потребуется база или свой написанный сохранятель. Всё круто, да?

Подстава с сериализацией

Как Вы поняли из текста выше, иногда бизнес-процесс следует ставить на паузу. Типичный пример: мы ждем ответа от пользователя (то есть используем Event Activity). В этом случае происходит обыкновенная сериализация (xml сериализация для Workflow 4.0+, бинарная для более старых версий). Я думаю, читатели сразу поняли, что здесь очень легко сохранить лишнее или же немного ошибиться при сохранении в релизе А, а загрузке в релизе Б. Типичный пример из Workflow 3.0 — Вы подписались на Event с помощью лямбы/анонимного метода. Ну и, если вы знаете, тем самым Вы создали новое поле класса, которое сохраняется в базу. И у вас упадет загрузка, так как упадет десериализация. Отсюда, большой совет: Весь рабочий код должен быть строго вынесен за пределы ваших Activity. Все поля должны сохраняться где-нибудь подальше от Workflow. В Activity храним самый минимум и самые простые типы. Пусть лучше пострадает внутренний дизайн, чем стабильность.
На самом деле, подстава здесь не закончилась. Самое классное начинается тогда, когда надо поменять набор полей. Например, в нашу RejectActivity из примера понадобиться добавить Reason. И вот тут код должен быть готов к тому, что старая RejectActivity не содержит этого поля. Для Workflow 4.0+ можно еще поменять сериализованное представление в базе, а вот для Workflow 3.0 такой способ не всегда подойдет (так как хранится сжатое бинарное представление), потому быстро всё это не обновить.

Засада с производительностью

На самом деле, у Microsoft Workflow целая серия недоработок. Причем, проблемы касаются как единичного выполнения (то есть ряд операций сделан не эффективно), так и распределения нагрузки. Однако, обо всем по порядку.

Когда следует сохраняться?

Представим, у нас идет бизнес процесс, в котором есть нулевые ожидания. Не важно, как они получились. Важно то, что они есть. Workflow трактует любое ожидание как отличный повод сохраниться, ну то есть сделать сериализацию, а потом загрузить опять нашу работу (правда, не совсем сразу, но не важно). Естественно, на время реакции это сказывается самым неблагоприятным образом. Отсюда совет: используйте Delay Activity как можно реже, а еще лучше — в связке с If Activity, которая проверит, что ждать, собственно, и не надо. Другой неприятный момент связан с тем, что если Вы сказали «ждать 5 суток», то простыми способами Вы не заставите Workflow всё-таки не ждать ничего, если наш instance уже в базе. Более того, если Workflow Runtime загрузит вашу работу в память, и увидит, что ждать следует еще кучу времени то она, как ни странно, просто оставит её в памяти. И будет ждать кучу времени. Отсюда, еще совет: из-за подобных проблем не используйте долгое ожидание. Лучше всего использовать много коротких или же просыпаться из-за внешнего Event'а, а уже Ваш внешний сервис разбудит процесс когда надо.

Распределенное выполнение

Если верить тем же статьям от Microsoft, Workflow прекрасно умеет распределять работу. Ну то есть Вы можете иметь несколько независимых серверов, каждый из которых будет брать немного заданий, выполнять их, брать следующие и так далее. В этом есть только один недостаток: это выдумка. Всё дело в том, что распределенная реализация Workflow — это крайне странное изделие. Оно работает по следующему алгоритму:
  1. Взять из базы ВСЕ не заблокированные рабочие процессы, которые сейчас могут выполниться И поставить им блокировку на пять минут
  2. Через две минуты: повторить пункт 1

Да, числа 2 и 5 можно поменять. Важно другое: самый первый везунчик заберет вообще всю работу из базы. Кстати, через две минуты он опять вычистит базу, даже если ему есть, чем заняться. Если он не уложится за пять минут для какого-нибудь рабочего процесса, то тут произойдет странная штука: он таки выполнит рабочий процесс (вызовет все WCF соединения и т.д.), попытается сохранить в базу данных, но у него ничего не выйдет (блокировки-то нету!). В итоге в памяти этого Workflow Runtime теперь уже навсегда останется этот ломаный объект. И он не выйдет из неё добровольно до тех пор, пока Вы физически не остановите процесс. Workflow Runtime не будет сам останавливаться, сделать он уже ничего не сможет. Великолепная реализация. Более красивый сценарий случится, если Вы настроите блокировку не на пять минут, а на более продолжительное время. В этом случае после остановки процесса эти записи будут заблокированы. Ну то есть Вам уже нельзя будет просто так останавливать процесс, что может очень негативно сказаться на Production платформе. Эта проблема решается крайне легко: для правильной распределенной работы Вам следует самостоятельно написать процедуры работы с базой (то есть, реализовать все процедуры для параллельной и распределенной работы, сделать свою реализацию WorkflowPersistenceService). Здесь есть, кстати, одна особенность: Вам не обязательно работать с MS Sql базой данных, можете поэкспериментировать с другими способами. На деле, задача решается с помощью простой файловой шары, работает быстро и правильно, однако это не модно.

Успешная работа под нагрузкой

На самом деле, её нет. Конечно, Microsoft утверждает, что все стало прекрасно, но они забыли про один маленький график: зависимость количества Activity в памяти от общего времени работы (а раньше оно было таким). На деле оно не поменялось:

image

Это квадратичный график. Тут важны не абсолютные значения времени, а зависимость: насколько долго у Вас будет всё работать, если сложность бизнес-процесса будет расти. Более того, на деле именно такая зависимость времени Execute от общего количества Activity в памяти, и не важно — один это рабочий процесс или несколько. Например, если у Вас 10 параллельных рабочих процессов, то на обработку каждой маленькой Activity будет тратиться больше ресурсов, чем если бы был один рабочий процесс. Или по другому: 10 параллельных задач обрабатываются дольше, чем 10 последовательных задач. Причем, с нелинейной зависимостью.
В предыдущей части я написал, как работает Persistence Service: он забирает всё из базы. На деле такой фокус из 5000 параллельных сложных рабочих процессов губителен для системы: она начинает работать с крайне низкой скоростью: 1-10 Activity в минуту (!!!). И это при условии, что процессор будет загружен почти на 100%. Проблема ясна, но как её решать? Решение: сделать свой обработчик Activity, переиспользовать Activity, cделать эмуляцию Ваших рабочих процессов. По факту Вам придется быстренько реализовать базовый компонент Workflow, который занимается стартом и остановкой Activity. Это потребуется, чтобы во-первых не допускать большое количество запущенных Activity на рабочий процесс (ибо всё тормозит), а во-вторых чтобы ускорить время сериализации/десериализации (побыстрее выгонять лишних из памяти). Microsoft Workflow никогда не удаляет отработанную Activity. Вам же придется всё реализовать так, чтобы завершенные Activity не находились в памяти.

Резюме

Я постарался описать часть проблем, которые Вас поджидают при работе с Microsoft Workflow. На деле здесь есть большое количество нюансов, но они более-менее решаемы, и я уверен, что Вы справитесь. По факту, если у Вас на работе встанет задача сделать свой настраиваемый бизнес процесс, то лучше все-таки начните использовать Microsoft Workflow. Для прототипа сойдет. Более того, при слабой нагрузке вся эта система может работать. Основные подставы известны — они выше, они вполне решаемы. К тому же, намного лучше работать с системой, от которой известно, что ожидать, чем с той, о которой есть только маркетинговая информация. Ну а если нагрузка начнет расти, Вы сможете модуль за модулем перенести на свою эффективную реализацию.
Игорь Манушин @imanushin
карма
21,0
рейтинг 0,0
Программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (44)

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

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

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

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

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

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

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

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

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

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

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

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

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

    Самое главное — workflow хорошо работает когда много параллельно ожидающих процессов. Например есть сценарий рассылки для новых клиентов, где каждому отправляется по одному письму в неделю. Реализация такого робота в коде получается громоздкой, а в wf — элементарной.
    • 0
      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
      



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

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

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

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

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

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

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


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

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


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

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


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

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

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


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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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

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

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