Windows workflow foundation как удалить
Обновлено: 07.07.2024
Мы продолжаем знакомство с технологиями Visual Studio 2005 и Windows Vista. Сегодня речь пойдет еще об одном нововведении, претендующем на революционность, – это Windows Workflow Foundation (WWF).
После написания первой программы «Hello, world!» в дальнейшем обучении будущих разработчиков обычно применяются блок-схемы, которые очень наглядно отображают логику программ. Но, к сожалению, блок-схемы исчезают сразу после того, как усвоены циклы и условные переходы. А ведь сложные программные конструкции напрочь лишены наглядности, что порождает множество проблем, с которыми вынуждены бороться все участники процесса создания ПО.
Существует, конечно, множество инструментов и методик, поддерживающих «визуализацией» различные этапы разработки, – от конструкторов кода до UML и RAD-сред, даже не предполагающих программирования. Но большинство из них не являются столь простыми и наглядными, как обычные блок-схемы. Нередко, однако, возвращение к старым идеям на более современном уровне дает весьма интересные результаты.
Так, среди значительного числа других нововведений WinFX Microsoft предлагает и свой взгляд на то, каким образом визуальная разработка на основе блок-схем может быть использована при создании приложений. Для этих целей рекомендуется применять некую интерпретацию понятия «workflow», реализованную в WWF.
Определимся с терминологией
Термин «workflow» достаточно распространен в IT-индустрии и воспринимается прежде всего в контексте систем электронного документооборота. Однако, как это часто происходит в том случае, когда вначале формируется рынок, а лишь потом согласовывается терминология, существует несколько различных толкований данного понятия, каждое из которых имеет определенное право на существование. Здесь мы не будем их анализировать, поскольку, как это станет ясно ниже, в случае WWF в «workflow» вкладывается смысл, несколько отличающийся от принятого в бизнес-системах.
При этом, как правило, подразумевается, что инструментарий workflow-моделирования обладает возможностями визуального проектирования, достаточными для создания сложных бизнес-систем фактически без программирования в традиционном понимании (т. е. без написания кода вручную).
Однако если рассматривать программирование в широком смысле – как создание набора инструкций, предусматривающих обратную связь и возможность повторного использования, то станет ясно, что под это определение вполне попадает моделирование любых рабочих процессов, так или иначе укладывающихся в модели workflow. Именно от этого отталкивалась Microsoft, разрабатывая WWF.
Важно понимать, что WWF не является ни реализацией какого-либо стандарта workflow вроде тех, которые определены WfMC, ни инструментом сугубо делового применения. Так что попытки сравнивать WWF с существующими на рынке workflow-систем готовыми бизнес-продуктами лишены всякого смысла, поскольку это универсальная и гибкая платформа, ориентированная прежде всего на визуальное программирование. И поэтому конструирование workflow-диаграмм с помощью WWF в той же мере программирование, в какой и создание блок-схем.
Архитектура
Архитектурно Windows Workflow Foundation состоит из нескольких уровней (таблица). На нижнем находится родительский процесс (Host Process). Характерно, что WWF работает не изолированно, а выполняется именно в рамках родительского процесса, который посредством стандартизированных интерфейсов предоставляет набор сервисов, определяющих функциональность WWF. Похожий подход применяется в Microsoft Windows Scripting Host (WSH) для обеспечения доступа к внутренним объектам.
| Уровень | Задача |
| Workflow Model | Поддержка предопределенных типов моделей, действий (activities) и соответствующего API |
| Runtime Layer | Исполнение модели и поддержка управления ее жизненным циклом |
| Hosting Layer | Интеграция с родительским процессом, предоставление интерфейсов для ключевых процессов WWF, реализация которых зависит от родительского процесса |
| Host Process | Обеспечение объектов и функциональности, которые полностью или частично доступны в WWF |
Ядром технологии WWF является уровень исполнения (Runtime Layer), который отвечает непосредственно за workflow-моделирование и содержит необходимые для этого службы. Он же управляет жизненным циклом (менеджмент состояний и активация) моделей, что позволяет исполнять значительное количество моделей, не расходуя понапрасну системные ресурсы в том случае, если часть из них находится в режиме ожидания.
На самом верху архитектуры WWF – уровень workflow-модели (Workflow Model Layer). Он отвечает за поддержку различных типов моделей, содержит предопределенные действия (activities) и реализует соответствующий API.
Также WWF включает встроенный визуальный редактор, благодаря которому можно конструировать модели без программирования. Хотя при необходимости они могут быть реализованы исключительно посредством программного кода, поскольку фактически представляют собой обычные классы. Кроме того, поддерживается возможность хранения описания моделей в XML-файлах, что позволит применять разнообразный инструментарий.
Сама технология WWF изначально ориентирована на расширения. Отдельные элементы workflow-модели – действия (activities) – выполнены в виде компонентов, которые могут создаваться сторонними поставщиками с помощью Visual Studio и WWF SDK. Помимо этого, WWF поддерживает динамическое обновление моделей во время исполнения, а также позволяет встраивать редактор моделей в собственные приложения.
Использование на практике
На текущий момент создавать и исполнять workflow-модели можно с помощью соответствующего расширения для Visual Studio 2005, доступного на сайте Microsoft.
WWF стандартно поддерживает два типа моделей – последовательные (sequential) и конечные автоматы (state machine). Первые представляют собой набор последовательно исполняемых действий и в наибольшей мере соответствуют классическим блок-схемам. Вторые позволяют моделировать переходы между несколькими предопределенными состояниями, что особенно актуально при конструировании сложных программных систем, например управления бизнес-процессами.
Эти два типа в определенной мере взаимозаменяемы – последовательная модель может быть преобразована в конечный автомат и наоборот. Однако каждый из них в наибольшей степени подходит лишь для определенного типа задач. Например, при большом количестве ветвлений и исключений последовательная модель может оказаться слишком запутанной и потерять наглядность, что сведет на нет все преимущества графического представления.
Несмотря на то что стандартно поддерживаются только два типа моделей, разработчики могут самостоятельно создавать дополнительные. Конструирование новых моделей на основе существующих не вызовет больших сложностей даже у относительно неподготовленного пользователя, обладающего лишь общими навыками описания алгоритмов. Для этого предназначен визуальный режим, в котором достаточно выбирать доступные действия (activities) и указывать их свойства и взаимосвязи. Их набор довольно обширен в стандартной поставке и включает возможности управления исполнением, построения циклов, распараллеливания, работу с исключениями, подсоединение к источникам данных, связывание с Web-службами и др. Создание же полностью оригинальных моделей требует весьма профессиональной работы.
Для построения условий система предлагает визуальный конструктор, позволяющий без программирования работать с бинарными операторами. Если же требуется создать более сложное условие, то применяются традиционные возможности одного из языков программирования – на уровне метода класса, реализующего модель.
Несмотря на то что workflow-модели можно создавать и исполнять сами по себе, полностью их потенциал раскрывается только при интеграции с приложением, обеспечивающим объекты для манипуляции. Для того чтобы модель получила доступ к внутреннему устройству родительского процесса, как уже говорилось, необходимо реализовать определенные интерфейсы, описанные в документации к WWF.
Модели также поддерживают режим отладки. Несмотря на определенные проблемы в текущей версии, Microsoft обещает, что будут доступны точки прерывания и пошаговое исполнение как в графическом представлении, так и в виде программного кода.
Модели конечных автоматов хорошо подходят для решения бизнес-задач
Даже такое поверхностное описание позволяет очертить некоторые сферы применения WWF. Данная технология хорошо подходит для решения задач управления бизнес-процессами и документооборотом, поскольку дает возможность наглядно представить их алгоритмику. Это может быть согласование условий контракта и обеспечение его выполнения или принятие заказов и их реализация с учетом индивидуальных особенностей и пожеланий каждого заказчика.
Также WWF хорошо подходит для формализации взаимодействия различных исполняющих устройств, и даже человека и машины. Эта особенность пригодится не только в бизнес-системах, но и в бытовой сфере. К примеру, посредством WWF можно создать некий «конструктор», предназначенный для управления логикой работы составляющих «умного дома» – от включения нагревательных приборов до алгоритма уборки помещений с помощью роботизированного пылесоса.
 |
| Последовательные модели в наибольшей степени схожи с обычными блок-схемами |
Не исключено, что WWF найдет применение и в самых обычных приложениях. К примеру, многих пугала необходимость изучать скриптовые языки для того, чтобы автоматизировать часто выполняемые рутинные операции. Наглядность и простота создания моделей в WWF может изменить отношение пользователей к несложному программированию и заметно повысить эффективность их труда.
Одно из первых «показательных» применений WWF будет реализовано в грядущей двенадцатой версии Microsoft Office. До сих пор для организации полноценного корпоративного документооборота с помощью этого пакета приходилось либо применять сторонние продукты, либо инвестировать значительные усилия в разработку решений на базе Exchange и/или SharePoint. Теперь базовые возможности обеспечения документооборота войдут в стандартную поставку Microsoft Office, а создавать новые сценарии движения документов опытные пользователи смогут самостоятельно без привлечения программистов.
Реальные преимущества
Попробуем выделить некоторые достоинства новой технологи.
Во-первых, использование WWF обеспечивает наглядность и прозрачность программной логики. Графическое представление, в отличие от кода, доступно для понимания не только разработчикам, но и другим участникам процесса создания ПО, в том числе, что особенно важно, заказчикам. WWF позволяет гораздо эффективнее по сравнению с альтернативными подходами отделить интерфейс пользователя и бизнес-логику приложений, упрощая коллективную разработку, модификацию решений и их портирование под новые платформы и разные типы клиентских устройств.
Во-вторых, наличие среды исполнения WWF и визуального дизайнера моделей во многих случаях поднимет на качественно новый уровень встроенные средства автоматизации/адаптации приложений. На наш взгляд, наглядное конструирование алгоритмов значительно удобнее и доступнее, чем, к примеру, аналогичные решения на базе скриптов.
В-третьих, WWF становится новым стандартным элементом платформы Windows с унифицированным интерфейсом и едиными правилами применения, что существенно упрощает задачу разработчиков по продвижению продуктов на его основе. Пример показывает сама Microsoft, использующая WWF в будущей версии Microsoft Office.
В-четвертых, следует отметить, что Microsoft заложила в архитектуру WWF очень важную функциональную особенность, которой могут похвастаться далеко не все поставщики нынешних workflow-систем, а именно, возможность динамически изменять выполняющиеся модели.
Перспективы
На наш взгляд, WWF имеет все шансы на успех и признание. Благодаря активной поддержке Microsoft эта технология обещает стать стандартом (на платформе Windows) при решении любых задач, требующих графического представления логики исполнения и гибкой ее модификации. Естественно, WWF не претендует на то, чтобы заменить привычное программирование, но разнообразить и дополнить его сможет вполне.
Не исключено также, что некоторые из существующих поставщиков откажутся от своих частных технологий и перейдут на использование ядра и дизайнера WWF. Это может стать стимулом развития рынков, в том числе и ПО автоматизации документооборота, за счет популяризации и унификации подходов.
Помню, еще в университете перед реализацией любого алгоритма мы описывали его в виде блок схемы, и только после этого переходили непосредственно к кодированию. Workflow, как одна из парадигм программирования, на ряду с процедурным и объектно ориентированным подходами, как раз и позволяет нам визуально реализовать любой процесс, используя набор предопределенных функциональных блоков (Activity), при этом, избавляя от его последующего кодирования.
Библиотека WF, являясь одной из реализаций парадигмы Workflow, предоставляет следующие основные возможности:
— богатый набор функциональных блоков;
— расширение набора стандартных функциональных блоков пользовательскими;
— сохранение и возобновление экземпляров Workflow в процессе их исполнения;
— использование Workflow дизайнера в вашем приложении;
— интеграция с WCF;
— пошаговая диагностика непосредственно в Workflow дизайнере;
— и многое другое.
Критерии применения
Как известно, каждой технологии своя область применения. Для определения необходимости использования WF при реализации конкретного алгоритма/процесса я применяю 3 критерия:
1. Реализация алгоритма/процесса постоянно меняется.
В нашей компании мы разработали подсистему Workflow, которая является ядром всех продуктов. Имея, к примеру, десятки клиентов наших продуктов, у которых десятки процессов, получаем сотни разных изменяющихся процессов.
2. Процесс/алгоритм имеет длительный срок выполнения.
В наших продуктах жизненный цикл процессов исчисляется днями и неделями. При этом, в случае сбоя или перегрузки сервера, процессы должны корректно возобновить и продолжить выполнение.
3. Нужно предоставить возможность изменения алгоритма/процесса конечному пользователю без вмешательства программиста.
Мы разработали свой собственный дизайнер, чтобы максимально упростить и облегчить редактирование процессов конечному пользователю (бизнес-аналитику). Это позволяет снять нагрузку с разработчиков. А возможность видеть и самим с легкостью менять свои процессы очень привлекательна для клиентов.
Таким образом, если актуально хотя бы одно из выше перечисленных требований, следует рассмотреть WF как возможный вариант реализации алгоритма/процесса.
Ознакомительный пример
В качестве ознакомительного примера использования WF я как раз и реализую Workflow процесс, который ответит на вопрос о целесообразности использования WF.
1. Создаю новый проект IsWWFUsefullSample используя шаблон Blank Solution:
2. Добавляю новый проект IsWWFUsefullSample.Activities используя шаблон Activity Designer Library:
3. Удаляю сущеcтвующий файл ActivityDesigner1.xaml и добавляю новый элемент используя шаблон Activity:
4. Открываю Activity в дизайнере и добавляю необходимые параметры типа Boolean:
— три входящих параметра соответствующих нашим критериям: IsLongRunning, IsChangeable, IsDesignerNecessary;
— один исходящий параметр для возврата результата: Result.
5. Для анализа входящих праметров использую три вложенных If Activities (Toolbox -> Control Flow -> If), хотя конечно можно обойтись и одним. Для присвоения результата использую Assign Activity (Toolbox -> Primitives -> Assign). В итоге получается следующий алгоритм:
6. Workflow процесс готов. Для его использования добавляю новое приложение IsWWFUsefullSample.TestClient на основании шаблона Workflow Console Application:
7. Удаляю файл Workflow1.xaml.
8. Добавляю ссылку на проект IsWWFUsefullSample.Activities.
9. Реализую Main метод. Он предлагает пользователю ответить на три вопроса, запускает процесс Workflow с полученными исходными данными и выводит результат вычисления.
namespace IsWWFUsefullSample.TestClient
using System;
using System.Activities;
using System.Collections.Generic;
using System.Linq;
using System.Text;
/// <summary>
/// Console program class.
/// </summary>
public class Program
/// <summary>
/// Program starting point.
/// </summary>
/// <param name="args">Program parameters.</param>
public static void Main(string[] args)
// Question answers
const string Yes = "yes";
const string No = "no";
var answers = new List<string> < Yes, No >;
// Create new activity instance
var activity = new IsWWFUsefull();
var parameters = new Dictionary<string, object>();
do
Console.WriteLine("Please, answer following questions to determine necessity of using WWF.");
Console.WriteLine();
// Read activity input parameters
parameters["IsLongRunning"] = ReadAnswer("Is process/algorithm long running?", answers) == Yes;
parameters["IsChangeable"] = ReadAnswer("Is process/algorithm frequently changed?", answers) == Yes;
parameters["IsDesignerNecessary"] =
ReadAnswer("Do you need a visual designer for your process/algorithm?", answers) == Yes;
When we imported designer workflow from one environment to other server we are getting above error when we try to open the workflow in designer 2013
New workflow creation is working fine but not this imported one.
MCTS Sharepoint 2010, MCAD dotnet, MCPDEA, SharePoint Lead
Ответы
According to your error message, it can be cause by the cache of SharePoint Designer.
You can try the solution that deleting the matching folder contents:
%APPDATA%\Microsoft\Web Server Extensions\Cache
%APPDATA%\Microsoft\SharePoint Designer\ProxyAssemblyCache
%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
Eric Tao
TechNet Community Support
Все ответы
According to your error message, it can be cause by the cache of SharePoint Designer.
You can try the solution that deleting the matching folder contents:
%APPDATA%\Microsoft\Web Server Extensions\Cache
%APPDATA%\Microsoft\SharePoint Designer\ProxyAssemblyCache
%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
Eric Tao
TechNet Community Support
I created new wrokflow completely and it is working fine.
Deleting the cache actually CAUSED my problem. I was no longer able to open my workflow. After I restored all the deleted files from my Recycle Bin, I was once again able to work on my workflow.
To completely replicate what I did: 1) Use Windows Explorer to delete the files; 2) Delete the files using Command Prompt; 3) Restore files from Recycle Bin. In between each step, I was re-launching Designer and attempting to open the workflow.
You need to restart SPD after installing the extensions
This worked for me - thanks :)
| James Boman BSc. MCP:EAD - |
Please try this to fix the issue:
When my SPD opened back up I clicked on Workflows, then highlighted one of them, R-clicked and chose Workflow Settings. When this opened up I chose Save and then Publish. After this I clicked on Edit Workflow and it opened no problem.
Основы Windows PowerShell Workflow: когда и зачем их использовать – Hey, Scripting Guy! Blog
Резюме: Приглашенный блогер Jeff Wouters рассказывает об основах рабочих процессов WindowsPowerShell 3.0 и о том, когда и зачем их использовать.
Jeff Wouters (BICT, MCITP, MCSA, MCSE) – технический консультант-фрилансер из Нидерландов. Его основной специализацией является высокая доступность и автоматизация с использованием продуктов Microsoft и Citrix, и таких технологий, как виртуализация, избыточность, кластеризация и репликация. Кроме того, его страстью является Windows PowerShell. И еще он – основатель Dutch PowerShell User Group в 2012 году.
Jeff выступал с докладами на таких конференциях, как E2E Virtualization Conference (ранее известна как PubForum), BriForum Chicago, и NGN (Dutch IT community). Вы можете найти Джеффа в социальных сетях (Twitter @JeffWouters | Facebook @JeffWouters | LinkedIn @JeffWouters) и в его блоге. Он выступает и пишет в основном о Windows PowerShell и виртуализации, но время от времени проскальзывает нечто, что вызывает его интерес.
Джефф также является одним из авторов проекта книги, где более 30 авторов со всего мира работают вместе над созданием книги о Windows PowerShell, которая будет издана в 2013 году.
Слово тебе, Джефф.
Когда был представлен Windows PowerShell 2.0, он подарил нам возможность удаленного выполнения команд. Спустя немного времени, вы можете видеть как множество продуктов используют эту технологию, так как она очень, очень мощная.
Windows PowerShell 3.0 принес рабочие процессы (workflow). Я осмелюсь предположить, что это окажет еще большее влияние, чем удаленная работа и поэтому я решил написать пост об этом с практической точки зрения и добавил тему в мой список «Нужно написать».
И чуть позже пришло письмо от Эда, с вопросом, будет ли мне интересно написать пост для блога «Hey, Scripting Guy!». По мере чтения письма я думал о моем намерении написать пост о рабочих процессах и решил что это будет отличной темой для блога Эда.
Что такое workflow?
Рабочий процесс – это в сущности несколько заданий, выполняемых последовательно, которые требуют некоторой координации, поскольку они могут выполняться на различных устройствах. По крайней мере так чем говорится в файле справки. Я обнаружил несколько более практических применений для рабочих процессов, о чем я и расскажу в этом посте.
С точки зрения дизайна, рабочие процессы могут повторяться, прерываться, перезапускаться, останавливаться и выполняться параллельно – больше об этом я расскажу в разделе «Для чего используются workflow?» далее в посте.
Хотя рабочие процессы очень мощные, нужно понимать, что они также и очень сложные. Можно запросто переусложнить скрипт, и поэтому, как и при работе с любыми большими скриптами, стоит сначала поразмыслить о том, что ваш скрипт будет делать, продумать его структуру, и лишь затем начинать его писать.
PowerShell содержит модуль PSWorkflow, который просто использует Windows Workflow Foundation. Рабочие процессы – это не часть Windows PowerShell. Это просто использование (очень разумное) технологии, которая уже присутствует в операционных системах Windows.
Мощь workflow
Для того, чтобы действительно оценить мощь рабочих процессов, я могу лишь посоветовать вам начать их использовать.
Но, конечно, это не то, что вы ждете от этого поста. Вам нужны примеры, так? Вместо того, чтобы дать вам кусок кода, я приведу пример, знакомый каждому администратору: Server Manager.
В Windows Server 2012 он был полностью переписан и стал значительно быстрее, поскольку теперь это фактически графическая оболочка вокруг Windows PowerShell и WMI. Кроме того, он позволяет вам управлять вашей средой из единой консоли, поскольку теперь он также использует рабочие процессы!
Когда вы развертываете решение на основе сценария из Server Manager, он знает (в соответствии со сценарием), в какой последовательности выполнять отдельные задачи. Он генерирует рабочий процесс для выполнения определенных действий и передает его на целевые серверы. Таким образом WMI, совместно с Windows PowerShell, рабочими процессами и удаленным выполнением представляет из себя немалую мощь.
Для чего используются workflow?
По моему мнению, только скрипты для развертывания, а также некоторые несложные скрипты для конфигурации и обслуживания позволят использовать рабочие процессы в простом и понятном виде. Вы увидите это в скриптах, приведенных в этом посте.
Вот почему, как и в случае с большими скриптами, я советую вам разделять большие рабочие процессы на меньшие части.
Разработчики называют это модульным программированием. Когда я обдумываю структуру скрипта – я называю это модульным обдумыванием. Когда я собираюсь написать скрипт, я думаю: Задачи -> Рабочие процессы -> Функции -> Модули… в таком порядке. В моем случае – это сильно облегчает мне жизнь.
Используйте workflowтолько тогда, когда нет другого выхода…?
Я видел, что кто-то – не помню точно, кто это был – написал, что вы должны использовать рабочие процессы только в том случае, когда действительно не существует иного варианта для выполнения задачи. Я не согласен с этим до определенной степени и позвольте мне объяснить, почему.
1. Если вы можете читать функции, вы также можете читать рабочие процессы – они читаемы.
2. Даже при использовании их основных возможностей – рабочие процессы очень мощные.
3. Во многих случаях при использовании рабочих процессов требуется намного меньше когда, чем при их неиспользовании и они по-прежнему остаются читаемыми.
4. Это может серьезно уменьшить время выполнения вашего скрипта.
5. Если вы используете только основные возможности рабочих процессов, но они все же удовлетворяют вашим потребностям, это не так сложно… действительно!
Единственное ограничение использования Windows PowerShell– это ваше воображение. Таким образом, если вы переусложните ваш скрипт – это не вина Windows PowerShell. Сказать, что вы должны использовать рабочие процессы только в тех случаях, когда нет другого выхода – это все равно что сказать, что вы должны использовать Windows PowerShell только при отсутствии других вариантов… звучит дико, правда?
Простые практические варианты использования workflow
Если мне нужно развернуть 50 виртуальных машин одинаковой конфигурации с именами VM от 1 до 50, я могу сделать это несколькими способами.
Первый потребует написания 150 строк кода – не совсем то, что мне бы хотелось.
Второй – это написать небольшой цикл:
В цикле задания выполняются последовательно. Этот тот случай, когда рабочий процесс может серьезно увеличить скорость выполнения вашего скрипта. При использовании workflow вы можете использовать параметр –Parallel в командлете ForEach, который позволяет выполнять 5 потоков одновременно. Таким образом, если ваше оборудование справится с нагрузкой, то создание виртуальных машин может стать до 5 раз быстрее!
Третий способ – это использование workflow:
foreach -parallel ($VM in $VMs)
Время выполнения первого скрипта в моем окружении составляло около 9 минут, время выполнения рабочего процесса – всего 2 минуты! Но если вы думаете, что рабочие процессы – статические, то я могу вам сказать, что рабочие процессы могут принимать параметры, так же как и функции. Следующий рабочий процесс в качестве входных параметров принимает имя виртуальной машины, число создаваемых виртуальных машин и размер виртуального диска:
foreach -parallel ($VM in $VMs)
Вы можете вызвать этот рабочий процесс так же, как и функцию:
New-VirtualMachines -VMName VM -VMCount 50 -VHDSize 15GB
Даже на простейшем уровне – это несложно, быстро, читаемо и может использоваться повторно!
А теперь вторая распространенная причина для использования рабочих процессов: выполнение заданий в определенной последовательности. Некоторое время назад я написал скрипт для одного из моих заказчиков. Этот скрипт выполнял следующие задачи:
| Number | Wait for number | Target | Task |
| 1 | WEB01 | Stop MyApp service | |
| 2 | 1 | WEB01 | Stop MyAppQueue service |
| 3 | 1,2 | FS01 | Remove MyAppQueue.xml |
| 4 | 1,2 | FS02 | Remove MyAppQueue.xml |
| 5 | 4,5 | WEB01 | Start MyAppQueue service |
| 6 | 5 | WEB01 | Start MyApp Service |
Если бы я не мог использовать рабочие процессы, то скрипт содержал бы достаточно много кода. Но при их использовании он выглядит следующим образом:
Invoke-Command -ComputerName WEB1
Invoke-Command -ComputerName FS1
Invoke-Command -ComputerName FS2
Invoke-Command -ComputerName WEB1
Invoke-Command -ComputerName WEB1
Заметка: я использовал Invoke-Command, потому что это просто, читаемо и соответствуем моим нуждам в этой конкретной ситуации. Я решил не использовать встроенные возможности рабочих процессов, и я не буду их рассматривать в этом посте.
Как вы видите, некоторые задачи выполняются в определенной последовательности и ждут, пока завершится предыдущее задание. Но так как обе задачи по удалению файлов зависят от тех же самых предыдущих шагов и не зависят друг от друга, они могут выполняться параллельно.
Функции против рабочих процессов
В чем отличие? Нет, подождите… это неверный вопрос, поскольку это совершенно разные вещи. Что общего? Точно, вот он, нужный вопрос!
Если вы знаете, как написать функцию, вы уже знаете большую часть того, что нужно для написания рабочего процесса. Workflow использует тот же синтаксис и принимает параметры таким же образом, как и функция. Продуктовая группа Windows PowerShell обладает весьма целостным подходом.
Давайте сравним рабочий процесс для развертывания виртуальных машин, приведенный ранее в посте, с функцией, выполняющей те же действия:
foreach ($VM in $VMs)
Как вы можете заметить, здесь только 2 отличия:
1. В первой строке вместо «workflow» – «function».
2. В 10 строке отсутствует параметр –Parallel. Функции не могут использовать этот параметр, только рабочие процессы.
Что еще можно сделать
Функция может вызывать рабочий процесс и рабочий процесс может вызывать функцию. Но так же как и функция может вызывать функцию, рабочий процесс может вызывать рабочий процесс – все еще следите за мыслью? Именно здесь все может внезапно стать очень сложным.
Кроме того, помните о ресурсах. Если вы одновременно создаете 5 виртуальных машин используя ForEach –Parallel, ваша среда может начать работать о-о-очень медленно. Таким образом, думайте пере тем как приступить к написанию скрипта. И если вы действительно хотите все усложнить, то это должно вам понравиться. Внутри блока sequence может находиться блок parallel. И внутри этого блока parallel может находиться блок sequence и т.д.
Для того, чтобы представить вам идею, я добавил несколько строк в приведенный ранее рабочий процесс Refresh-MyApp:
Invoke-Command -ComputerName WEB1
Invoke-Command -ComputerName WEB1
Invoke-Command -ComputerName FS1
Invoke-Command -ComputerName FS2
Invoke-Command -ComputerName FS1
Invoke-Command -ComputerName FS2
Invoke-Command -ComputerName FS1
Invoke-Command -ComputerName FS2
Invoke-Command -ComputerName SQL1
Invoke-Command -ComputerName SQL2
Invoke-Command -ComputerName SQL3
Invoke-Command -ComputerName SQL1
Invoke-Command -ComputerName SQL2
Invoke-Command -ComputerName SQL3
Invoke-Command -ComputerName FS1
Invoke-Command -ComputerName FS2
Invoke-Command -ComputerName WEB1
Invoke-Command -ComputerName WEB1
Далее представлена таблица, объясняющая взаимоотношения разных частей скрипта:
Цель этого поста
Основная моя цель в этом посте была показать вам, насколько простыми могут быть рабочие процессы. Я думаю, вы смогли оценить их мощь, даже при использовании их простейших возможностей. Сходство с функциями облегчает их изучение и использование для выполнения параллельных задач. Может быть это пригодиться вам для выполнения ваших задач. Если вы новичок в рабочих процессах – начните с основ, приведенных в этом посте и двигайтесь дальше.
WorkFlow – это рабочий процесс (WF), представляющий собой набор технологий, включенных в PowerShell и доступных на любом компьютере под управлением Windows 7/8, Server 2008/ 2008 R2/ 2012. Это особый вид сценария PowerShell, который очень похож на функцию. Однако при запуске он преобразует рабочий процесс в код Windows Workflow Foundation (WWF) и передает для выполнения, после чего его содержимое будет отличаться от скрипта.
Основа рабочих процессов
WorkFlow – это комбинация традиционных и современных инструментов программирования для объявления рабочего процесса и выполнения действий, помогающих определить логику, поток управления и время выполнения полученного приложения. WWF - это процесс использования языка более высокого уровня для написания ПО с целью повышения производительности труда разработчиков, упрощения управления и быстрой адаптации. Среда выполнения WWF не только выполняет рабочий процесс, но и предоставляет сервисы и функции, важные при написании логики ПО, такие, как сохранение состояния, маркировка и возобновление бизнес-логики, что приводит к эффективности потоков и процессов.
Модель программирования WWF была переработана, что сделало ее более простой и надежной. Активность является ее основным базовым типом и представляет как процессы, так и операции. WW больше не нужно создавать во время выполнения для вызова рабочего процесса, ее можно просто оформить как экземпляр и выполнить, упрощая модульное тестирование и сценарии ПО, в которых разработчик не хочет испытывать трудности при настройке конкретной среды. Наконец, модель программирования становится полностью декларативной композицией действий без кода, что также упрощает разработку.
Использование Net Framework
Некоторые из основных возможностей WW перечислены ниже:
- Визуальное представление процесса.
- Динамическое изменение во время выполнения.
- Длительность функционирования.
Существует два основных типа WW:
- Последовательные, используются для четко определенных процессов.
- Конечного автомата, организованы как диаграммы конечного автомата, обычно используемые для WW с оперативным взаимодействием, включая Workflow-перевод.
Операции и службы
Операции WorkFlow – это рабочие процессы, состоящие из одной или нескольких операций, являющихся строительными блоками WW. Набор готовых действий предоставляется разработчикам, также можно создавать свои собственные. Службы - механизм выполнения WW с использованием собственных функций при выполнении экземпляра. Можно использовать службы в WW Foundation, настроить доступные службы или создать собственные. WW в реальной жизни могут иметь длительный и непредсказуемый срок выполнения. Windows WW Foundation обрабатывает все операции и может при необходимости сохранять рабочие процессы.
Компенсация-транзакции в мире WW отличаются от традиционных. В тех случаях, когда есть длительные процессы, невозможно точно откатить назад набор действий при возникновении исключений. Вместо этого WW допускает «компенсацию», которая в простом выражении является действием, предпринимаемым для покрытия эффекта части транзакции и уже была завершена. Визуальная природа определения WW приводит к требованию отслеживания хода выполнения рабочего процесса. WW Foundation предоставляет службы для отслеживания состояния экземпляров процессов.
Проект с открытым исходным кодом Designer
Дизайнер WF предлагает множество функций из коробки, его легко расширить, вот почему многие компании интегрировали его в свои продукты и решения.
Существует 3 типа рабочих процессов, которые используют в соответствии с требованиями бизнес-кейса, их можно использовать вместе в смешанном режиме, а также возможна группировка WF/Activity:
- Последовательный WW - простая линейная логика.
- Блок-схема WW - очень интуитивно понятная логика блок-схем.
- WW конечного автомата - мощный, переходы состояний, события, триггеры.
WW можно создавать визуально, программно и с помощью сценариев PowerShell:
- Создание WW - Visual Studio.
- Создание WW – Код.
- Создание WW - Powershell Azure.
Сериализация выполняется с помощью Xaml, что делает WW очень гибкими:
- Сериализация WW Xml.
- Сериализация WW - Xaml Code.
- Сериализация WW - Powershell Visual Xaml.
Встроенные библиотеки
Основной уровень Sharepoint
Workflow Manager является очень сложным компонентом Foundation и основным уровнем Sharepoint. Его применяют в пользовательских решениях и в Rehosted WF Designer. Он предлагает много полезного: REST Endpoint & Client API, Multi-tenancy (области) и масштабирование, управление хранилищем Базы Данных, отслеживание и мониторинг, управление экземплярами, полностью декларативный авторинг.
Тем не менее развертывание не является легким при выполнении с помощью пользовательских установщиков, и оно навязывает решению реализацию версий, экземпляров, хранилищ данных. Журнал результатов выполнения Workflow Foundation предлагает высокий уровень прозрачности в отношении логики процесса. Пользовательское отслеживание участников легко внедрить и адаптировать конкретному варианту использования. Метод Track вызывается всякий раз, когда рабочий процесс генерирует Tracking Record, содержащий данные выполнения WF: журналы и аналитические данные.
Стандартная модель SwTracking Participant является хорошей отправной точкой для реализации отслеживания WW. Функция Persistency, ключевая для длительных рабочих процессов, доступна сразу после установки в WF, если будут использованы доступные хранилища данных, Workflow Identity и действия для сохранения. Помимо включения новых сценариев, эта функция также помогает масштабировать ресурсы по вертикали, когда есть WW в качестве модели сервиса, и выполняет много рабочих процессов параллельно на одном и том же сервере/VM:
- состояние WF будет удалено из памяти до следующего шага или триггера;
- восстанавливает его из хранилища данных постоянства
- возобновляет процесс выполнения.
Автоматизация задач в iOS Apple
Перед началом автоматизации задачи загружают систему Workflow из App Store, запускают его и нажимают вкладку «Мои рабочие процессы » или вкладку «Галерея», если нужно использовать предварительно выполненное действие. В правом верхнем углу выбирают «Создать рабочий процесс» и один из четырех WW.
Выбрав WW, проводят пальцем вправо, чтобы открыть меню «Действия». Отсюда можно выполнить поиск нужного действия или выбрать действие из списка доступных предложений. Выбрав действие, перетаскивают его вправо, чтобы добавить в текущий WW. Если нужно включить дополнительное действие, которое будет выполняться после первого, проводят пальцем вправо и повторяют процесс.
Для того чтобы изменить WW, нажимают на значок шестеренки в правом верхнем углу. Результирующее меню будет содержать множество различных настроек, что позволит изменить тип рабочего процесса. Когда все выполнено, нажимают «Готово» в правом верхнем углу, чтобы оставить WW в приложении, или выбирают «Добавить на главный экран», чтобы запустить WW в браузере.
PowerShell. Сценарии
Платформа для работы и обмена
SharePoint Workflow - отличная платформа для совместной работы и обмена. Однако в любое время, когда потребуется какое-то одобрение бизнес-процесса, необходимо задействовать возможности рабочего процесса.
Существует несколько способов создания WW в SharePoint:
- Без рабочего процесса - если нужно простое одобрение или какое-либо уведомление, то можно просто использовать возможность оповещений в SharePoint вместе с некоторыми столбцами метаданных.
- Функция подтверждения контента - использование встроенной функции одобрения контента. Она допускает односторонние утверждения контента, но можно выполнять работу во многих простых сценариях утверждения.
- Готовые рабочие процессы - доступно несколько готовых (встроенных) рабочих процессов, которые позволяют создавать более сложные конфигурации.
- SharePoint Designer - это бесплатный инструмент, доступный от Microsoft, который создает более сложные рабочие процессы с параллельным и многоступенчатым последовательным одобрением. Особенность SPD заключается в том, что может потребоваться некоторое время, чтобы ознакомиться с тем, как он работает, а сам инструмент иногда может быть довольно сложным.
- Microsoft Flow - облачный продукт, который интегрируется с SharePoint и многими другими приложениями.
- Сторонние инструменты WW, которые можно интегрировать с SharePoint.
Виды готовых процессов:
- WW утверждения.
- WW сбора отзывов.
- Сбор подписей Workflow.
- WW с тремя состояниями.
Готовые WW хороши в очень специфических сценариях и не допускают каких-либо значительных настроек, часто связанных с настраиваемыми бизнес-процессами.
Преимущества и недостатки
- Разные источники данных, в основном базы данных, являющихся частью WW приложения.
- Периодически изменяющаяся логика приложения, в которой изменяются несколько шагов в WW.
- Изолированные выходные данные (разветвленная схема), которые требуют сложной логики.
- Пакетные входы, которые являются частью начального WW и имеют неопределенные временные рамки.
- Максимальная производительность и гибкость приложений в отношении совместимости.
- гибкость;
- отчеты о времени выполнения;
- интеграция с коммуникационным фундаментом;
- динамическая конфигурация;
- визуальный дизайн логики приложения.
Основным недостатком является сложная кривая обучения, когда большинство программистов сталкиваются с трудностями при адаптации к методам проектирования WW.
За последние 20 лет большинство программ перешло с языков низкого уровня на языки высокого уровня. В сегодняшней отрасли для решения повседневных задач, таких как выделение памяти и переписывание кода для разных машин, эта программа просто незаменима.
Читайте также: