Tutorial №2#
Расширенный Портал Счетов#
Описание приложения: расширенный портал счетов и приложение для утверждения счетов#
Мы собираемся расширить приложение Invoice Inventory, которое мы создали здесь, добавив возможности для пользователей, которые создают счета, чтобы сделать это для разных отделов, добавив важные данные счета, такие как данные поставщика и внутреннее кодирование счета, а также предоставив пользователям инвентаризации счета возможность отправлять свои счета на рассмотрение и утверждение.
Мы также добавим новое приложение Bill Approvals. Приложение для утверждения счетов автоматически преобразует любой счет, отправленный на проверку и утверждение, в счет, затем выполняет автоматизированный рабочий процесс проверки и утверждения и, наконец, обновляет исходный счет, присваивая ему надлежащий статус.
Разные пользователи, роли пользователей и отделы#
У нас будет три основных группы пользователей, определяющих, что они делают в приложении:
Одна команда сможет вводить новые счета и отправлять их на утверждение.
Другая группа будет отвечать за рассмотрение отправленных счетов и их утверждение на основе отдела, назначенного специальным кодом расходов (например, IT.HARDWARE ) .
И последняя группа будет отвечать за утверждение руководством счетов с общей стоимостью выше определенного порога (> 10 000 в нашем примере).
Кроме того, пользователи будут определяться отделами, к которым они принадлежат. В частности, пользователи могут принадлежать к следующим отделам:
Маркетинг
IT
Управление
Пользователи из отделов маркетинга и IT смогут создавать и просматривать только счета, относящиеся к их соответствующим отделам. Пользователь из отдела управления сможет просматривать и утверждать счета, созданные на основе счетов из любого отдела.
Дополнительные данные счета#
В дополнение к исходным данным заявки на выставление счета, перечисленным здесь , следующие данные будут частью счета:
Поставщик (Supplier) — ссылка на запись в Каталоге поставщиков, в которой перечислены все предварительно зарегистрированные поставщики.
Код расходов (Spend Code) — ссылка на запись в каталоге кодов расходов, в которой перечислены все существующие коды расходов. Коды будут специфичны для одного из отделов — IT или маркетинга (например, «MKTG.Supplies»).
Комментарии (Comments) — поле с комментариями (например, комментарии от утверждающих)
Кроме того, мы создадим отдельный общий компонент — Каталог, в котором будет храниться вся соответствующая информация о жизненном цикле счета (например, Draft, Under Review, Approved, etc.), и который будет использоваться в качестве ориентира для всех других компонентов, которые могут понадобиться. для отображения статуса
Каталог Поставщиков (Supplier Catalog)#
Supplier Catalog это список всех предварительно зарегистрированных поставщиков, которых можно выбрать при выставлении счета.
Информация о каждом поставщике будет включать:
Supplier Name - название поставщика в произвольной форме
Supplier Contact Name - имя лица, которое является вашим контактным лицом на стороне поставщика
Supplier Contact Email - адрес электронной почты лица, которое является вашим контактным лицом на стороне поставщика
Supplier Legal Address - юридический почтовый адрес поставщика, строка произвольной формы
Supplier Payment Account # - Платежный счет поставщика
( необязательный/будущий ) Кроме того, во время отправки счета-фактуры пользователю, выполняющему ввод счета-фактуры, должна быть доступна возможность добавления нового поставщика.
Spend Type Codes Catalog - Каталог Кодов Счетов#
Каталог кодов счетов — это список внутренних кодов, которые позволяют правильно распределять расходы внутри компании. Список кодов будет специфичен для одного из отделов — например, информационных технологий или маркетинга.
Структура Каталога кодов типов расходов будет состоять из следующего:
Название кода расходов (например, MKTG.Supplier или IT.Services)
Отдел, которому принадлежит код (например, IT или маркетинг)
Расширение возможностей Invoice Inventory#
Для пользователей из группы ввода счетов (invoice entry team) будут предоставлены следующие возможности:
Возможность видеть свои существующие отправленные счета (invoices) для своего отдела и статус этих счетов
Возможность добавить новый счет (invoice), установить код расходов, который будет показывать, на какой бюджет пользователь отправляет счет, и сохранить счет как черновик
Редактировать счета, которые находятся в статусе «Draft»
Возможность отправить счет в статусе «Draft» для рассмотрения и утверждения, получить уведомление о результате (утвержден или отклонен) и увидеть скорректированный статус счета по мере его прохождения через процесс утверждения
Как только счет находится в любом статусе, кроме «Draft», он больше не будет редактируемым (все поля формы пользовательского интерфейса будут установлены на «Disabled»)
Приложение для рассмотрения и утверждения счетов (Bill Approval Application)#
В приложении для рассмотрения и утверждения счетов будут показаны все счета, отправленные на утверждение, и текущий статус каждого счета (на основе Каталога Статусов). Все поля счета будут равны исходным полям счета. Информация о счете не будет доступна для непосредственного редактирования пользователями Bill Portal.
Все счета будут автоматически созданы из черновиков счетов (Draft invoice), отправленных на утверждение пользователем Invoice Inventory. Каждому вновь созданному счету будет присвоен статус STATUS_UNDER_REVIEW, а исходный статус счета также будет обновлен до статуса STATUS_UNDER_REVIEW.
После создания каждый счет будет виден только соответствующей группе утверждения счетов на основе кода расходов, назначенного счету (либо IT, либо MKTG). Все поля счета, кроме комментариев, будут недоступны для редактирования (установите значение «Disabled»).
Если пользователь открывает счет со статусом STATUS_UNDER_REVIEW, этот пользователь увидит две кнопки: «Утвердить» (Approve) и «Отклонить» (Reject).
Нажатие кнопки «Отклонить» приведет к тому, что счету будет присвоен статус STATUS_REJECTED, соответствующий статус счета будет обновлен. Никакие другие изменения в этом счете или счете-фактуре не допускаются.
Нажатие кнопки «Подтвердить» приведет к одному из следующих действий:
Если общая стоимость меньше 10 000, то статус счета будет установлен на STATUS_APPROVED, соответствующий статус счета будет установлен на STATUS_APPROVED, поле «Комментарии» будет синхронизировано. Также не допускается внесение каких-либо других изменений в этот счет.
Если общая стоимость превышает 10 000, статус счета будет установлен на MANAGEMENT_REVIEW. Соответствующий статус счета также будет установлен на MANAGEMENT_REVIEW.
Если пользователь Management открывает счет со статусом MANAGEMENT_REVIEW, этот пользователь увидит две кнопки — Approve и Reject.
Нажатие кнопки «Reject» приведет к тому, что для счета будет установлено значение STATUS_REJECTED, а статус соответствующего счета будет изменен на STATUS_APPROVED. Никакие другие изменения в этом счете не допускаются.
Нажатие кнопки «Approve» приведет к тому, что для счета будет установлено значение STATUS_APPROVED, а статус соответствующего счета будет изменен на STATUS_APPROVED. Никакие другие изменения в этом счете не допускаются.
Архитектура Расширенного Портала Счетов#
Новое приложение будет состоять из нескольких компонентов, некоторые из которых являются расширенными старыми версиями, а некоторые — совершенно новыми версиями. В учебных целях мы создадим каждый компонент с нуля, однако в реальной жизни вполне возможно просто расширить существующий компонент, чтобы он соответствовал новой архитектуре дизайна.
Будут следующие компоненты:
Supplier Catalog - новый компонент, в котором будут перечислены все поставщики и их ключевые параметры, такие как контактная информация, номер счета и т. д.
Shared Status Catalog - новый компонент, в котором будут перечислены все доступные значения статусов для всех счетов.
Spend Type Codes Catalog - новый компонент, в котором будут перечислены все доступные коды типа расходов и сопоставлены с обязанностями группы IT или отдела маркетинга
Invoice Inventory Portal - расширенная версия исходного компонента Inventory, включающая:
Новая ссылка на внешний каталог Shared Status вместо старого поля Enum
Ссылка на новый Supplier catalog
Ссылка на новый Spend Type Codes catalog
A Dataflow который копирует конкретный счет-фактуру в компонент портала инвентаризации счетов и устанавливает статус Under_Review
Настройка правил безопасности, которая позволит только людям из IT-команды добавлять, просматривать и отправлять на утверждение счета, принадлежащие IT-команде (на основе кода расходов), а также людям из отдела маркетинга добавлять, просматривать и отправлять на утверждение только счета, принадлежащие в отдел маркетинга
Учетные записи для пользователей отдела IT и маркетинга
Bill Inventory Portal - новый компонент, который:
Содержит все счета, отправленные IT- и маркетинговыми командами на утверждение
Разрешить просмотр счетов в статусе «Under Review» и их утверждение или отклонение соответствующими утверждающими лицами отдела с использованием встроенного рабочего процесса
Разрешить дополнительное утверждение счетов выше заранее определенной суммы (10 000) руководством с использованием встроенного workflow
Автоматически устанавливать статус полностью утвержденных или отклоненных счетов на «Approved» или «Rejected» соответственно, а затем автоматически обновлять исходный статус счета с помощью встроенного потока данных и передавать комментарии, если он был добавлен утверждающим лицом
Иметь настройку безопасности, которая позволит только членам групп утверждения IT и маркетинга видеть только счета для IT и маркетинга, соответственно, на основе кода расходов, установленного в счете
Supplier Catalog#
Настройка компонента#
Имя должно быть Tutorial #2: Supplier Catalog
Следующие поля должны быть добавлены со следующими параметрами (для деталей, посмотрите Appendix I со снимками экрана, показывающими, как каждое поле должно быть настроено):
Supplier Name (String, Required, Primary Key, Query)
Contact Name (String)
Contact Email (String)
Legal Address (String)
Account (String, Required, Minimum Length: 5)
Должна быть добавлена форма Add/View Supplier, все поля из шага 2 выше будут редактируемыми, а также должны быть добавлены кнопки Save и Back to all Suppliers
Должна быть добавлена страница с формой All Suppliers, с контролем DataGrid показывающим все поля из шага 2, с включенной кнопкой Add , и полем Action выставленом в значение Edit Record
Кнопка Save должна быть выставлена в Action: Execute Workflow, и новое workflow Save должно быть добавлено с единственным шагом Update Model
Кнопка Back to All Suppliers должна иметь Action:Command Type выставленным в значение Navigation Back
Настройки Settings/Menu должны быть выставлены на Show Component in Main Menu в положении On (выбрано)
Компонент должен быть сохранен и помечен готовым к публикации.
Ввод данных для Supplier Catalog Component#
После того, как Supplier Catalog настроен, опубликован и запущен, он должен выглядеть следующим образом после заполнения.
Используйте кнопку «Add », чтобы открыть форму «Add/View» и добавить столько поставщиков, сколько пожелаете. Мы рекомендуем иметь как минимум 2 или 3 поставщиков для целей этого урока, как показано на снимке экрана выше.
Как только все поставщики будут добавлены, работа с компонентом «Supplier Catalog» завершена.
Компонент Spend Type Codes Catalog#
Настройка компонента#
Имя нового компонента должно быть Tutorial #2: Spend Type Codes Catalog
Следующие поля должны быть добавлены со следующими параметрами (для деталей, посмотрите Appendix II со снимками экрана, показывающими, как каждое поле должно быть настроено):
Code Name (String, Required, Primary Key)
Type (String, Enum: 0|IT, 1|Marketing)
Должна быть добавлена форма Add/View Spend Type, все поля из шага 2 выше будут редактируемыми, а также должна быть добавлена кнопка Save и Back to all Spend Codes
Должна быть добавлена страница с формой All Spend Codes, с контролем DataGrid показывающим все поля из шага 2, с включенной кнопкой Add , и полем Action выставленом в значение Edit Record
Кнопка Save должна быть выставлена в Action: Execute Workflow, и новое workflow Save должно быть добавлено с единственным шагом Update Model
Кнопка Back to All Spend Codesдолжна иметь Action:Command Type выставленным в значение Navigation Back
Настройки Settings/Menu должны быть выставлены на Show Component in Main Menu в положении On (выбрано)
Компонент должен быть сохранен и помечен готовым к публикации.
Ввод данных для Spend Type Codes Catalog#
После того, как Spend Type Codes Catalog настроен, опубликован и запущен, он должен выглядеть следующим образом после заполнения.
Используйте кнопку «Add », чтобы открыть форму «Add/View» и добавить столько Spend Codes, сколько пожелаете. Мы рекомендуем иметь как минимум 5 или 6 Spend Codes для целей этого урока, как показано на снимке экрана выше.
Как только все поставщики будут добавлены, работа с компонентом «Spend Code Types Catalog» завершена.
Компонент Shared Status Catalog#
Component design setup#
Имя нового компонента должно быть Tutorial #2: Shared Status Catalog
Следующие поля должны быть добавлены со следующими параметрами (для деталей, посмотрите Appendix III со снимками экрана, показывающими, как каждое поле должно быть настроено):
Code Name (String, Required, Primary Key)
Type (String, Enum: 0|IT, 1|Marketing)
Должна быть добавлена форма Add/View Status, все поля из шага 2 выше будут редактируемыми, а также должна быть добавлена кнопка Save и Back to all Statuses
Должна быть добавлена страница с формой All Statuses, с контролем DataGrid показывающим все поля из шага 2, с включенной кнопкой Add , и полем Action выставленом в значение Edit Record
Кнопка Save должна быть выставлена в Action: Execute Workflow, и новое workflow Save должно быть добавлено с единственным шагом Update Model
Кнопка Back to All Statuses должна иметь Action:Command Type выставленным в значение Navigation Back
Настройки Settings/Menu должны быть выставлены на Show Component in Main Menu в положении On (выбрано)
Компонент должен быть сохранен и помечен готовым к публикации.
Ввод данных для Shared Statuses Catalog#
Используйте кнопку «Add», чтобы открыть форму «Add/View» и добавить идентификатор состояния и имя пользовательского интерфейса состояния из списка дизайнов здесь.
После настройки, публикации и открытия Shared Status Catalog он должен выглядеть следующим образом после заполнения.
После того, как все общие коды состояния будут добавлены, вы закончите работу с компонентом Spend Type Codes Catalog.
Настройка Компоненты Invoice Portal , Часть №1#
Настройка Invoice Portal пкомпоненты должна выполняться в несколько этапов.
Во-первых, мы настроим основные компоненты, которые будут включать настройку полей данных, форм добавления/просмотра и формы всех счетов.
Во-вторых, мы настроим возможность отправки счетов в статусе «Draft» на утверждение, используя комбинацию возможностей Workflow и Dataflow платформы.
Наконец, мы настроим роли, права и группы безопасности, предоставив надлежащий доступ к данным счетов на основе прав пользователя.
Настройка компонента#
Как и общие каталоги, основной портал счетов (Invoice Portal) представляет собой простое приложение, описанное в первом уроке здесь , которое состоит из модели данных, формы добавления/просмотра и формы для всех счетов. Основные шаги, необходимые для настройки основного портала счетов-фактур, описаны ниже и предполагают знакомство с первым уроком.
Имя нового компонента должно быть Tutorial #2: Invoice Portal
Следующие поля должны быть добавлены со следующими параметрами (для деталей, посмотрите Appendix IV со снимками экрана, показывающими, как каждое поле должно быть настроено):
InvoiceID (String, Primary Key)
Invoice Name (String)
Total Value (Number)
Due Date (Date)
Comment (String)
Затем необходимо установить ссылки на вновь добавленные каталоги следующим образом (см. экраны настройки в Appendix IV):
Supplier (Property Type:Catalog, Component: Tutorial #2 Supplier Catalog)
SpendType (Property Type:Catalog, Component: Tutorial #2 Spend Type Codes)
StatusID (Property Type:Catalog, Component: Tutorial #2 Shared Status)
Должна быть добавлена форма Add/View Invoice, где должны быть сделаны редактируемыми все поля из шага 2 выше, кроме поля «Status», и с кнопками «Save» и «Back to all invoices»
Должна быть добавлена страница «All invoices» используюя контроль DataGrid, показывающей все поля из шага 2, с включенной кнопкой «Add» и с настройкой «Action:Edit Record».
Кнопка Save должна быть выставлена в Action: Execute Workflow, и новое workflow Save должно быть добавлено с единственным шагом Update Model
Кнопка Back to All Invoices должна иметь Action:Command Type выставленным в значение Navigation Back
Настройки Settings/Menu должны быть выставлены на Show Component in Main Menu в положении On (выбрано)
Компонент должен быть сохранен и помечен готовым к публикации.
Настройка Автоматизации формы Add/View Invoice#
Как описано в расширенном дизайне приложения здесь, нам потребуется некоторая автоматизация форм для нашего расширенного приложения Invoice Portal.
Во-первых, нам нужно убедиться, что поле «Статус» не может быть изменено пользователем.
Во-вторых, нам нужно убедиться, что для всех новых счетов-фактур установлен статус STATUS_DRAFT.
Наконец, нам нужно убедиться, что все счета, которые НЕ находятся в статусе STATUS_DRAFT, не могут быть изменены кем-либо, то есть все поля будут отключены.
Это делается с помощью встроенных возможностей скрипта Python. Показываем, как их использовать.
Сначала перейдите к компоненту «Tutorial #2: Invoice Portal» и выберите «Settings», а затем вкладку «Component Script», как показано на снимке экрана ниже.
Здесь у нас есть место для размещения скрипта Python (версия IRON PYTHON). Нужный нам скрипт будет выглядеть так, с комментариями для уточнения деталей.
#Добавить библиотеку IronPython , импортирующую имена системных CRL (.NET) в Python
import clr
#Получить и запомнить ссылку на Component’s DataModel
datamodel = context.DataModel.Model
# Вывести внутренний код в консоль браузера
print("datamodel?", datamodel)
# context.Model.Id проверить внутренний Id инстанса компонента
if (context.Model.Id == 0):
# Если context.Model.Id равно 0, тогда этот инстанс еще не был сохранен
# Это значит что мы создаем новый invoice
# Поскольку это новый invoice,
# Мы поставим его статус на STATUS_DRAFT (внутренний код DB ID=137)
# Вы можете посмотреть внутренний ID вашего статус выведя значение системного параметра Id
# например добавив колонку с Id в data grid
datamodel.InvoiceStatusID = 137
# Затем мы разрешим для редактирования все поля, кроме поля Status
context.Properties.InvoiceIdUI.Disabled = False
context.Properties.InvoiceNameUI.Disabled = False
context.Properties.DueDateUI.Disabled = False
context.Properties.TotalValueUI.Disabled = False
context.Properties.CommentUI.Disabled = False
context.Properties.SpendCodeUI.Disabled = False
context.Properties.SupplierUI.Disabled = False
# И разрешим показывать панель с кнопками
context.Properties.InvoiceSaveApprovePanel.Visible = True
# Если это не новый invoice, и если его статус не STATUS_DRAFT
if (datamodel.InvoiceStatusID != 137):
# Тогда мы выключим все поля через выставление Disabled=True
context.Properties.InvoiceIdUI.Disabled = True
context.Properties.InvoiceNameUI.Disabled = True
context.Properties.DueDateUI.Disabled = True
context.Properties.TotalValueUI.Disabled = True
context.Properties.CommentUI.Disabled = True
context.Properties.SpendCodeUI.Disabled = True
context.Properties.SupplierUI.Disabled = True
# И скроем панель с кнопками Save и Submit for approval
context.Properties.InvoiceSaveApprovePanel.Visible = False
# Конец скрипта
На этом первая часть настройки компонента Invoice Portal будет завершена. Чтобы сделать вторую часть, сначала нам нужно будет настроить основной компонент Bill Portal. Если вы хотите сразу перейти ко второй части настройки компонента Invoice Portal, перейдите сюда.
Настройка Bill Portal, Часть №1#
Настройка компонента#
Как и Invoice Portal, Bill Portal по своей сути представляет собой простое приложение для работы с данными, как описано в первом учебнике здесь. Он состоит из модели данных, формы добавления/просмотра счета и формы просмотра всех счетов. Основные шаги, необходимые для настройки основного портала рассмотрения и утверждения счетов, описаны ниже и предполагают знакомство с первым уроком.
Имя нового компонента должно быть Tutorial #2: Bill Portal
Следующие поля должны быть добавлены со следующими параметрами (для деталей, посмотрите Appendix V со снимками экрана, показывающими, как каждое поле должно быть настроено):
BillID (String, Primary Key)
Bill Name (String)
Total Value (Number)
Due Date (Date)
Comment (String)
Затем необходимо установить ссылки на вновь добавленные каталоги следующим образом (см. экраны настройки в Appendix V):
Supplier (Property Type:Catalog, Component: Tutorial #2 Supplier Catalog)
SpendType (Property Type:Catalog, Component: Tutorial #2 Spend Type Codes)
StatusID (Property Type:Catalog, Component: Tutorial #2 Shared Status)
Должна быть добавлена форма View Bill, где должны быть добавлены все поля из шагов 2 и 3 выше, и с кнопками «Save» и «Back to all invoices»
Должна быть добавлена страница «All bills» используя контроль DataGrid, показывающий все поля из шага 2 и 3, с вЫключенной кнопкой «Add» и с настройкой «Action:Edit Record».
Кнопка Save должна быть выставлена в Action: Execute Workflow, и новое workflow Save должно быть добавлено с единственным шагом Update Model
Кнопка Back to All Bills должна иметь Action:Command Type выставленным в значение Navigation Back
Настройки Settings/Menu должны быть выставлены на Show Component in Main Menu в положении On (выбрано)
Компонент должен быть сохранен и помечен готовым к публикации.
Дополнительные кнопки будут добавлены в Части 2 настройки компоненты Bill Portal
Настройка Invoice Portal, Часть №2#
Настройка Dataflow & Workflow#
Quick introduction to Dataflows and Workflows#
Platform включает в себя два важных компонента, отвечающих за автоматизацию операций — Dataflow и Workflow.
Dataflow — это набор автоматизированных операций, направленных на управление данными, которые могут быть получены из форм, компонентов, через внешние интерфейсы или другими способами. Данные можно автоматически запрашивать, преобразовывать и передавать как внутри компонентов, так и извне через интеграционные API. Кроме того, Dataflow могут выполнять рабочие процессы и даже манипулировать пользовательским интерфейсом, например открывать определенные формы или компоненты.
Workflow это последовательности действий на основе конечного автомата , которые могут быть как автоматизированными действиями, такими как выполнение потоков данных, обновление данных, так и взаимодействиями с пользователями-людьми, такими как получение подтверждения пользователя или отправка пользователю уведомления различными способами и форматами. Workflow также включают возможность проверки таких условий, как «если/то» или несколько сценариев переключения (кейса).
Как Dataflow, так и Workflow состоят из нескольких настраиваемых неограниченных этапов, каждый из которых содержит один или несколько шагов, а также зависимости между этапами.
Как Dataflow, так и Workflow настроены на вызов (выполнение) при действии пользователя из пользовательского интерфейса (например, с помощью элемента управления пользовательского интерфейса «Button»).
Настройка Dataflow для Invoice Portal#
Для Invoice Portal мы будем использовать Dataflow для сбора данных из счетов со статусом STATUS_DRAFT, а затем для автоматического создания соответствующего счета в компоненте Bill Portal, а также для установки статуса счета в UNDER_REVIEW в обоих компонентах.
Чтобы создать новый Dataflow, сначала нам нужно добавить кнопку «Save & Submit for Approval» и установить для ее действия значение Actions→Command Type на «Execute Workflow», как показано ниже.
Это создаст новый workflow под названием «Save & Submit for Approval», как показано выше.
В этом workflow мы должны добавить один этап без имени со следующими двумя шагами:
Стандартный шаг Update Model, чтобы убедиться, что мы обновили все свойства до актуальных данных из формы
Шаг с типом Integrations->Execute Data Flow… Затем мы перейдем к этому шагу и отредактируем имя Dataflow на «Create Bill». Это создаст dataflow с именем Create Bill, как показано выше.
Далее мы настроим dataflow для выполнения следующих действий:
Получить обновленный набор свойств (модель данных) из Workflow. Это делается с помощью типа действия «Get Workflow Model» из группы действий «Input».
Настройте переменную для Dataflow с правильным кодом для статуса DEPARTMENT_REVIEW, используя действие «Execute Script» из группы действий «Transformation», используя шаг «Lookup Reference» и наш каталог Tutorial #2: Shared Status.
Создайте новый счет с обновленным статусом, используя действие «Update Entry» и установив в поле BillStatus наш новый статус используя переменную из шага 2.
После этого нам нужно будет найти и обновить наш исходный счет с новым статусом.
Для этого мы сохраним наш InvoiceNumber как временную переменную, а затем обновим наш Invoice, используя эту переменную и наш новый статус.
Затем мы запустим рабочие процессы утверждения счетов (которые необходимо добавить на портал счетов до этого).
Наконец, мы перейдем на нашу страницу «All bills» и завершим dataflow, используя действие «Write Response».
Результирующий dataflow должен выглядеть так, как показано ниже. Подробные скриншоты для настройки каждого шага потока данных можно найти в Приложении IV.
Настройка ролей для Invoice Portal#
Краткое введение в систему безопасности (security)#
Система безопасности в Platform состоит из следующих основных элементов.
Аутентифицированные пользователи (authenticated users) — пользователи, у которых есть профиль в системе плюс логин и пароль (или другие средства аутентификации, такие как единый вход OAuth 2.0 SSO), которые должны быть аутентифицированы перед доступом к приложениям, созданным с помощью платформы
Контексты безопасности (Security Contexts) — элементы приложений, созданных с использованием платформы, которые можно использовать для управления доступом пользователя к данным и действиям в приложении. Существуют следующие типы контекстов безопасности:
Компоненты: общий каталог, для которого установлен флаг ограничения доступа (Restrict Access) в значение True.
Каждый элемент контекста безопасности компонентов может иметь параметры разрешений на чтение, обновление и/или удаление.
Cases: компонент с workflow, в который включен шаг типа «Get User Confirmation».
Каждый Case может разрешить или запретить доступ к определенному шагу получения подтверждения пользователя.
Кнопки (Buttons) с параметром «Restrict Access» также создают контекст безопасности и могут использоваться для создания наборов разрешений и ролей.
Наборы разрешений (Permission Sets) — объект безопасности с уникальным именем, который объединяет одно или несколько разрешений для одного или нескольких элементов контекста безопасности
Роли — комбинация Permission Sets, которые используются для определения конкретной комбинации разрешений для пользователей, играющих определенную роль в приложении (например, предоставление людям с ролью IT_Approver доступа ко всем IT-запросам, а также утверждение конкретных IT-запросов). Пользователям назначается одна или несколько ролей через форму настроек Studio -> Access -> Users -> User Name
Настройка Системы Безопасности для Invoice Portal#
Для Invoice Portal мы будем использовать Spend Types Catalog в качестве контекста безопасности (установите для параметра «Restrict Access» значение «True» в настройках компонента).
Затем мы создадим два разрешения — UserITRead и UserMKTGRead и разрешим разрешение UserITRead на чтение всех статусов, связанных с IT-кодами, и разрешение UserMKTGRead на чтение всех статусов, связанных с маркетинговыми кодами. Результат должен выглядеть следующим образом:
Получив эти два разрешения, мы теперь создадим две роли: одну для IT и одну для маркетинга. Затем мы перейдем к выбору контекста для каждой роли. Например, для роли IT мы назначим UserITRead всем кодам, связанным с IT (IT.*). На скриншоте ниже показано, как это делается для кода IT.HW.
Затем мы сделаем то же самое для MKTGUser_Read для кодов MKTG.*, предоставив им разрешение UserMKTG_Read. Наконец, мы создадим двух пользователей — UserIT и UserMKTG и назначим им соответствующее разрешение ( ITUser_Read или MKTGUser_Read ).
Теперь, после того как мы сохраним и опубликуем наше обновленное приложение Invoice Portal, любой из этих двух пользователей сможет войти в приложение Invoice Portal, но будет видеть только существующие счета с кодами IT.* или MKTG.*, а также использовать только эти типы кодов при создании новых счетов. В то же время администратор (или любой другой пользователь, которого мы захотим), у которого есть права на чтение, сможет просматривать все счета и отправлять счета, используя любой доступный код.
Настройка Bill Portal, Часть №2#
Настройка формы View#
Как было описано в расширенном дизайне приложения вверху, нам потребуется некоторая автоматизация форм для нашего приложения Bill Portal.
Во-первых ****, нам нужно сделать так чтобы никакие поля, кроме комментариев, не могли быть изменены любым пользователем.
Для этого нам нужно перейти к каждому из элементов управления формой, перейти к свойствам элемента управления формы (используя значок «Settings») и выставить флажок «Disabled». Ниже приведен пример элемента управления Bill Name:
Во-вторых, нам нужно будет создать несколько кнопок для утверждения и соответствующие рабочие процессы для их поддержки. Получившееся нижняя часть формы должна выглядеть как показано внизу.
Кнопка Back to All Bills должна быть настроена на Command Type NavigateBack или Open Page/All Bills.
Кнопка Send to Approve должна быть выставлена на Action→Command Type: Execute Workflow, что создаст Send to Approve workflow как показано выше. Мы настроим его чуть позже.
В третьих, нам понадобится Component script на Python который будет показывать эти кнопки только в правильных случаях.
import clr
datamodel = context.DataModel.Model
# Заблокировать все поля формы
context.Properties.FormStatus.Disabled = True
#Спрятать кнопку SendToApprove потому что это workflow вызывается
#из-за пределов компоненты внешним Dataflow
context.Properties.SendToApprove.Visible = False
#Выставить контекст для approval workflow
context.Properties.ApproveActions.WorkflowInstanceId = context.Workflows["SendToApprove"].WorflowInstanceId
#Если bill в статусе Approved или Rejected, спрятать панели аппрува
if (datamodel.BillStatus == 139 or datamodel.BillStatus == 140):
context.Properties.BillApprovePanel.Visible = False
context.Properties.ApproveActions.Visible = False
# Если bill в статусе REVIEW, показать панели аппрува
if (datamodel.BillStatus == 138 or datamodel.BillStatus == 141):
context.Properties.BillApprovePanel.Visible = True
context.Properties.ApproveActions.Visible = True
Настройка Approval Workflows & Dataflows#
Поскольку у нас будут довольно сложные, многоуровневые рабочие процессы утверждения счетов с автоматическим обновлением статусов, настройка workflow и dataflow у нас будет намного больше сложной, чем у нас была для портала отправки счетов.
Основной workflow для утверждения организует все остальные рабочие процессы и потоки данных и будет выглядеть так, как показано ниже.
Вкратце, мы:
Использовать Get User Confirmation ативность в workflow чтобы получить ответ от авторизованного пользователя. Так будет сделан Departmental level approval.
Как только мы получим ответ от пользователя, мы проверим его на соответствие Reject или Approve
Если это Reject, мы вызовем Reject/Department dataflow которое обновит и bill и исходный invoice статус на STATUS_REJECT, и закончит workflow
Если это Accept, мы продолжим наш workflow
В продолжении workflow, мы проверим необходимость в Management Level approval используя dataflow Check if 2nd Approval Needed. Результат проверки будет записан в NeedManagementApproval поле как True или False
Если NeedManagementApproval будет false, мы запустим dataflow FinalAccept/Department которое обновит статус на STATUS_APPROVED, и потом закончит workflow
Если NeedManagementApproval будет true, мы опять используем ативность Get User Confirmation в нашем workflow чтобы получить ответ от пользователя с правами management
Как только мы получили ответ от management пользователя, мы проверим его опять на Approver или Reject, запустим соответствующий dataflow для обновления статуса, и завершим наш workflow
Настройка “Check If 2nd Approval Needed” workflow#
Наше workflow “Check If 2nd Approval Needed” будет выглядеть следующим образом.
Тут мы получим значение поля TotalValue, сравним его с порогом в 10000 и если TotalValue больше порога, выставим поле NeedManagementApproval в True, а иначе в False.
Финально, как пример dataflow для обновления статусов Accept/Reject, внизу показан пример настроенного FinalAccept/Management dataflow:
В этом dataflow, мы сначала находим наш bill используя его BillNumber, и ставим статус APPROVED. Мы потом находим оригинальный invoice используя тот же BillNumber, и также выставляем ему статус APPROVED.
Аналогично работают все другие dataflow для обновления статусов на Approved/Rejected.
Роли для компонента Bill Portal#
В дополнение к настройке доступа к экземплярам компонента с использованием контекста безопасности данных Spend Codes, как описано выше для безопасности портала счетов, нам также потребуется настроить роли действия утверждения как для утверждения уровня отдела, так и для уровня управления. Для простоты мы позволим тем же пользователям UserIT и UserMKTG, которые могут отправлять счета, утверждать их на уровне отдела. Затем мы настроим учетную запись системного администратора по умолчанию для утверждения руководством.
Чтобы настроить все вышеперечисленное, мы создадим разрешение под названием DepartmentApprovers , которое сможет получить доступ к шагу «Get Department Approval» рабочего процесса «Send to approve» нашего компонента Tutorial #2: Internal Bills Portal. Кроме того, эта роль будет иметь доступ не только к чтению, но и к обновлению каталога Spend Type Code, так как именно они будут обновлять его.
Далее мы создадим две новые роли — утверждающий для IT (IT Approver) и утверждающий для маркетинга (Marketing Approver), которые будут устанавливать доступ к кодам контроля расходов для пользователей IT и маркетинга соответственно, как показано ниже в примере для кода IT.HW.
То же самое должно быть установлено для IT.SW и IT.Services . Для MKTG.* следует выбрать два набора разрешений — DepartmentApprovers и UserMKTG_Read .
Наконец, у каждого из наших обучающих пользователей — userIT и userMKTG — должны быть добавлены роли IT-утверждающего и маркетингового утверждающего соответственно. Пример для userIT показан ниже.
Чтобы завершить настройку безопасности, нам нужно добавить утверждающее руководство. Для простоты у нас будет один утверждающий менеджер, который может утверждать счета как за IT, так и за маркетинг.
Для этого мы создадим набор разрешений ManagementApprovers , который предоставит доступ к этапу «Get Management Approval Step» нашего рабочего процесса «Send to Approve», а также полный доступ к каталогу «Spend Type Codes», как показано ниже.
Затем мы создадим роль ManagementApproval , в которой будет включена роль ManagementApprovers для всех кодов расходов в каталоге кодировщиков типов расходов, как показано ниже для примера IT.HW.
Наконец, мы создаем нового пользователя с именем user_management и назначаем ему новую роль ManagementApproval , как показано ниже
Теперь второе учебное приложение полностью настроено, и вы можете использовать созданных вами пользователей для его тестирования.