Вибір засобу створення робочих процесів (sharepoint foundation)
Що таке робочий процес? Він складається з двох основних елементів: форм, які робочий процес використовує при взаємодії з користувачами, і логіки, яка визначає поведінку процесу. Для розуміння того, як створюються робочі процеси, необхідно мати уявлення про ці елементи.
Так як робочий процес взаємодіє з користувачем через веб-браузер, для відображення форм процесу використовується ASP.NET. Ці форми визначаються як сторінки ASPX. Протягом життєвого циклу робочого процесу форми можуть відображатися на чотирьох етапах.
Зміна: творець робочого процесу може дозволити його зміни під час виконання. Наприклад, в виконуваний процес можна дозволити додавання учасників або перенесення терміну виконання завдання. Якщо цей параметр використовується, то робочий процес повинен відображати форму в цій точці, що дозволяє учасникам внести зміни.
Робочий процес збору відгуків
Доступні види діяльності відображаються в панелі інструментів в лівій частині екрана. Розробник може перетягнути ці елементи на робочу поверхню і таким чином вказати етапи робочого процесу. Потім можна буде вказати властивості дій у вікні "Властивості", яке знаходиться в правому нижньому кутку.
У бібліотеці основних дій Windows Workflow Foundation зберігається група базових дій, описаних раніше. Служби Microsoft SharePoint Foundation також надають набір дій, спеціально розроблених для робочих процесів. Нижче перераховані найбільш важливі елементи.
OnWorkflowActivated: стандартна початкова точка робочого процесу. Крім усього іншого, ця дія може приймати інформацію від адміністратора SharePoint через форму зіставлення, якщо робочий процес зіставлений з бібліотекою документів, списком, типом контенту або сайтом. Також він може приймати відомості, що надаються формою при запуску процесу. Кожен робочий процес повинен починатися з цього дії.
CreateTask: дія створює завдання, пов'язану з конкретним користувачем зі списку завдань. Наприклад, в описаному раніше сценарії затвердження цю дію використовувалося для додавання завдання в список, який використовували всі учасники. Крім того, ця дія має властивість SendEmailNotification. Якщо вона була придбана, то система автоматично відправляє по електронній пошті повідомлення особі, для якого створено завдання.
OnTaskChanged: дія приймає інформацію з форми виконання завдання. У сценарії затвердження, який був описаний раніше, це дія використовувалося для прийому даних від кожного учасника при затвердженні документа.
CompleteTask: дія позначає завдання як виконане.
DeleteTask: дія видаляє завдання зі списку.
OnWorkflowModified: дія приймає з форми зміни інформацію, яку потім можна використовувати для зміни поведінки цього примірника робочого процесу. Якщо творець робочого процесу не включає в дію будь-які екземпляри, запущений робочий процес не можна буде змінити.
SendEmail: дія відправляє по електронній пошті повідомлення зазначеній особі або групі осіб.
Типовий робочий процес починається з дії OnWorkflowActivated, за яким слідує дія CreateTask, призначає завдання учаснику робочого процесу. Після цього можна використовувати стандартне дію BAL While, що дозволяє дочекатися виконання завдання. Щоб дізнатися, коли це станеться (користувач може внести в задачу кілька змін і поставити прапорець у формі виконання завдання після завершення), всередині дії While слід виконати дію OnTaskChanged, яке отримує дані, введені користувачем у форми. Коли користувач виконає завдання, можна буде виконати дію CompleteTask і DeleteTask. Потім можна передати робочий процес наступному учаснику, присвоївши йому завдання за допомогою дії CreateTask, і т. Д. Звичайно, можна виконувати і інші дії, наприклад відправляти повідомлення електронної пошти, реєструвати інформацію в списку історії або навіть включити дію BAL Code, що дозволяє запустити довільний код.
Незалежно від обраного стилю розробник зобов'язаний визначити не тільки логіку робочого процесу, а й форми ASPX, які він буде використовувати. Для цього використовується файл з ім'ям element.xml. Це шаблон, в якому розробник вказує форму (при її наявності), яку потрібно відображати в кожній з чотирьох дозволених точок.
Для настройки обміну даними між робочим процесом і використовуваними формами ASPX розробнику необхідно виконати певні дії. Простір імен Microsoft.Windows.SharePoint.Workflow надає розробникам об'єктну модель. За допомогою типів цього простору імен робочий процес Windows SharePoint Services може обмінюватися даними з формою ASPX.
Створивши робочий процес і його форми, розробник повинен упакувати їх в компонент. Після цього адміністратор SharePoint встановлює цей компонент (разом зі складками робочого процесу) в глобальний кеш збірок відповідної системи. Тепер новий робочий процес відображається для адміністратора як шаблон, який можна порівняти з бібліотекою документів, списком, типом контенту або сайтом.
Тут виникає питання: чим же відрізняється логіка, створена в Microsoft SharePoint Designer? Чому адміністратори SharePoint з готовністю погоджуються розгорнути в своїх системах робочі процеси, створені за допомогою цього засобу? Справа в тому, що створений в Microsoft SharePoint Designer робочий процес може використовувати тільки дії з контрольованого адміністратором списку. Крім дій, наданих службами SharePoint Foundation, адміністратор може включити в список настроюються дії, створені розробником. Точно визначивши допустимі дії робочого потоку, адміністратор SharePoint може бути впевнений, що розгортання створеної за допомогою Microsoft SharePoint Designer логіки не призведе до дестабілізації системи.
У зв'язку з тим що служби Microsoft SharePoint Designer створені не для розробників, а для співробітників інформаційних центрів і призначені в основному для простих сценаріїв, в них використовується інша модель створення робочих процесів, що відрізняється від використовуваної в розміщеному в Visual Studio конструкторі Workflow Foundation. Замість графічного підходу в Microsoft SharePoint Designer використовується підхід на основі правил, що нагадує знайомий багатьом майстер правил в Microsoft Outlook. На малюнку нижче показано, як користувач Microsoft SharePoint Designer визначає дії в робочому процесі. Зверніть увагу, що кілька дій в цьому робочому процесі виконуються паралельно, деякі дії - послідовно. У більш ранніх версіях SharePoint Foundation підтримувалося лише послідовне виконання дій.
Порядок обробки робочого процесу
Кожен крок може містити умову і дію. Умова визначає, чи буде виконано дію даного кроку, як в прикладі з оператором If. показаному вище. Як дії можна вибрати, наприклад, призначення одержувача події, збір тверджень і багато іншого. На практиці кожна дія виконується будь-якою дією SharePoint Foundation. Дії збігаються з діями Visual Studio і конструктора робочих процесів WF. Крім того, в список можуть входити інші дії, дозволені адміністратором SharePoint для цього сайту, в тому числі і створені розробниками.
Служби SharePoint Foundation надають безліч функціональних можливостей для створення робочих процесів, орієнтованих на обробку документів. При цьому служби є платформою, призначеною тільки для розробки і виконання: тут відсутні функції робочих процесів, які користувач може використовувати безпосередньо. У робочих процесів, що працюють під управлінням SharePoint Foundation, є й інші обмеження (наприклад, неможливість взаємодії з учасниками через клієнтські програми Office).