Планування створення робочих процесів (sharepoint server 2018)

Що таке робочий процес? В основному він складається з двох елементів: форм, які процес використовує при взаємодії з користувачами, і логіки, яка визначає поведінку процесу. Для розуміння того, як створюється процес, необхідно мати певні знання про обох елементах.

Робочий процес обмінюється з користувачами даними через веб-браузер і, відповідно, відображає форми за допомогою ASP.NET. Ці форми визначаються як сторінки ASPX. Робочий процес потенційно може відображати форми на чотирьох етапах життєвого циклу.

Зміна: творець робочого процесу може дозволити зміну запущеного процесу. Наприклад, можна додати в виконуваний процес учасників або перенести дату готовності завдання. Якщо цей параметр використовується, робочий процес повинен відобразити форму, що дозволяє учаснику внести зміни.

Як тільки форми InfoPath робочих процесів створені, вони приєднуються до робочого процесу за допомогою файлу workflow.xml точно також, як це відбувається з формами ASP.NET. Однак на відміну від форм ASP.NET, розробникам не потрібно писати користувальницький код для переміщення даних між формами InfoPath робочих процесів і робочим процесом. Замість цього SharePoint Server і InfoPath надають посилання, яка полегшує роботу розробників робочих процесів.

Робочий процес збору відгуків

Доступні види діяльності відображаються в панелі елементів в лівій частині екрана. Розробник може перетягнути ці елементи на робочу поверхню і таким чином вказати етапи робочого процесу. Потім можна буде вказати властивості дій у вікні "Властивості", яке знаходиться в правому нижньому кутку.

У бібліотеці основних видів діяльності WF зберігається група основних дій, описаних раніше. Крім того, в SharePoint Server є набір дій, спеціально розроблених для створення робочих процесів. Нижче перераховані деякі з найбільш важливих.

OnWorkflowActivated: стандартна початкова точка робочого процесу. Крім усього іншого, ця дія може приймати інформацію від адміністратора SharePoint через форму зв'язку в тому випадку, якщо робочий процес пов'язаний з бібліотекою документів, списком, типом контенту або веб-сайтом. Також він може приймати відомості, що надаються через форму ініціації при запуску процесу. З цього дії починається будь-який робочий процес.

CreateTask: дія створює завдання, пов'язану з конкретним користувачем зі списку завдань. Наприклад, в сценарії затвердження, який був описаний раніше, це дія використовувалося для додавання завдання в список, який використовували всі учасники. Крім того, у цієї дії є властивість SendEmailNotification. Якщо вона була придбана, система автоматично відправляє по електронній пошті повідомлення особі, для якого створено завдання.

OnTaskChanged: дія приймає інформацію з форми виконання завдання. У сценарії затвердження, який був описаний раніше, це дія використовувалося для прийому даних від кожного учасника при затвердженні документа.

CompleteTask: дія позначає завдання як виконане.

DeleteTask: дія видаляє завдання зі списку.

OnWorkflowModified: дія приймає з форми зміни інформацію, яку потім можна використовувати для зміни поведінки цього примірника робочого процесу. Якщо творець робочого процесу не включає в дію будь-які екземпляри, запущений робочий потік не можна буде змінити.

SendEmail: дія відправляє по електронній пошті повідомлення зазначеній особі або групі осіб.

Типова схема простого робочого процесу починається з дії OnWorkflowActivated, потім йде дію CreateTask, призначає завдання учаснику робочого процесу. Потім можна використовувати стандартне дію BAL While, що дозволяє дочекатися виконання завдання. Щоб дізнатися, коли це станеться (користувач може внести в задачу кілька змін і поставити прапорець у формі виконання завдання, коли закінчить), всередині дії While потрібно виконати дію OnTaskChanged, яке отримує дані, введені користувачем у форми. Коли користувач виконає завдання, можна буде виконати дію CompleteTask і DeleteTask. Далі можна передати робочий процес наступному учаснику, присвоївши йому завдання за допомогою дії CreateTask, і т. Д. Звичайно, можна виконувати і інші дії, наприклад відправляти повідомлення електронної пошти, реєструвати інформацію в списку історії або навіть включити дію BAL Code, що дозволяє запустити довільний код.

Всі дії з SharePoint Server дозволяють робочому процесу працювати в середовищі SharePoint. Вибір бізнес-логіки робочого процесу належить тільки творцю. Фактично розробник робочого процесу Windows SharePoint Services вільно може створювати і використовувати власні дії. Необов'язково використовувати тільки дії SharePoint Server і WF.

Як вже говорилося раніше, Windows Workflow Foundation підтримує послідовні і статичні робочі процеси. Робочий процес, створений за допомогою конструктора робочих процесів WF, також може використовувати будь-які з цих дій. Для цього SharePoint Server додає в Visual Studio типи проектів, по одному на кожен стиль робочого процесу.

Незалежно від обраного стилю, розробник зобов'язаний визначити не тільки логіку робочого процесу, а й форми ASPX або форми InfoPath, які він буде використовувати. Для цього використовується файл з ім'ям element.xml. Це шаблон, в якому розробник вказує форму (при наявності), яку потрібно відображати в кожній з чотирьох точок, де процес може це зробити.

Для настройки обміну даними між робочим процесом і використовуваними формами ASPX розробнику потрібно дещо зробити. Простір імен Microsoft.Windows.SharePoint.Workflow надає розробникам об'єктну модель. За допомогою типів з цього простору імен робочий процес може обмінюватися даними з формою ASPX.

Створивши робочий процес і його форми, розробник повинен упакувати їх в так звану функцію. Після цього адміністратор SharePoint встановлює функцію (включаючи складання робочого процесу) в глобальний кеш збірок відповідної системи. Тепер новий робочий процес відображається для адміністратора як шаблон, який можна пов'язати з бібліотекою документів, списком, типом контенту або веб-сайтом.

Тут же виникає питання, чим же відрізняється логіка, створена в Microsoft SharePoint Designer? Чому адміністратори SharePoint з готовністю погоджуються розгорнути в своїх системах робочі процеси, створені за допомогою цього засобу? Справа в тому, що створений в Microsoft SharePoint Designer робочий процес може використовувати тільки дії з контрольованого адміністратором списку. Крім дій, наданих в SharePoint Server, адміністратор може включити в список настроюються дії, створені розробником, але не зобов'язаний це робити. Точно визначивши допустимі дії робочого процесу, адміністратор SharePoint може бути впевнений, що розгортання створеної в Microsoft SharePoint Designer логіка не дестабілізує систему.

У зв'язку з тим що Microsoft SharePoint Designer створений не для розробників, а для інформаційних працівників і призначений в основному для простих сценаріїв, він використовує іншу модель створення робочих процесів, не ту, що використовується у вхідному в Visual Studio конструкторі WF. Замість графічного підходу в Microsoft SharePoint Designer використовується підхід на основі правил. У чомусь це нагадує майстер правил в Microsoft Outlook - засіб, з яким багато хто знайомий. Екран нижче ілюструє настройку етапу робочого процесу, виконувану користувачем Microsoft SharePoint Designer. Зверніть увагу, що робочий процес виконує деякі дії паралельно, а деякі послідовно. У більш ранніх версіях SharePoint Server забезпечувалося тільки послідовне виконання дій.

Робочий процес порядку обробки

Кожен крок може містити умову і дію. Умова визначає, чи потрібно виконувати дію етапу, як в операторі If вище. Вибір включає такі дії, як привласнення обробника події, збір підтверджень і багато іншого. На практиці кожна дія виконується дією SharePoint Server, а використовувані дії такі ж, як і в Visual Studio і конструкторі WF. Список дій також може включати і будь-які інші дії, дозволені адміністратором SharePoint для даного веб-сайту, включаючи користувацькі дії, створені розробниками. У SharePoint Server є також набір спеціальних дій, що дозволяють користувачам налаштовувати загальну парадигму тверджень або збору відгуків, які входять в процес "створення набору завдань і очікування їх виконання", в спеціальному конструкторі Microsoft SharePoint Designer.

Хоча призначений для користувача інтерфейс кошти виглядає зовсім не так, як при графічному підході, який я використав в Visual Studio і конструкторі робочих процесів WF, Microsoft SharePoint Designer створює стандартний робочий процес WF. На практиці виходить послідовний, паралельний або комбінований процес з умовами, вираженими за допомогою механізму правил WF. При цьому у створених таким чином процесів є деякі обмеження. Наприклад, на відміну від процесів Visual Studio і конструктора WF, запущені процеси не можна змінювати під час виконання, а крім того, створювати можна тільки послідовні і паралельні процеси - кінцеві автомати не підтримуються. Крім того, готові процеси потрібно реєструвати в конкретній бібліотеці, списку і на сайті. Можливе створення спільного шаблону робочого процесу, який пізніше можна пов'язати з будь-бібліотекою, списком або типом контенту. Хоча це обмежує можливості використання процесів, але і значно спрощує розгортання. Фактично, коли користувач закінчує створювати робочий процес за допомогою Microsoft SharePoint Designer, засіб автоматично розгортає і активує його на цільовому сайті. Цей метод значно простіше багатоетапного процесу розгортання, який необхідний для процесів, створених в Visual Studio і конструкторі процесів WF.

SharePoint Server надає розширені функціональні можливості для створення документно-орієнтованих робочих процесів. При цьому вони тільки представляють собою платформу розробки і виконання. Функцій робочих процесів, які користувач може використовувати безпосередньо, тут немає. У робочих процесів, створених тільки в SharePoint Server, є й інші обмеження, наприклад неможливість взаємодії з учасниками через клієнтські програми Office.