6.1.3 Реализация, разработка бизнес процессов
6.1.3.1 Разработка сценариев
В рамках проекта были разработаны 2 сценария из-за отсутствия функций с необходимой функциональностью:
· Сценарий, записывающий новое значение пользовательского свойства, хранимой на портале формы InfoPath.
· Сценарий, извлекающий файл приложенный к форме InfoPath, хранимой на портале, на файловую систему.
Разработка сценариев включает в себя следующие этапы: написание кода сценария; отладка кода сценария; сохранение готового сценария в процессе или подпроцессе.
Написание кода сценария можно производить как непосредственно в диалоговом окне функции сценария, так и в любом другом редакторе, или при помощи Visual Studio.NET - с последующей вставкой полученного кода в функцию процесса. Последний вариант предпочтительнее, так как позволяет избежать грубых ошибок форматирования, синтаксиса, и преобразования типов.
Код сценария должен располагаться в классе DVScript, в пространстве имен DVScriptHost:
namespace DVScriptHost
{
class DVScript
{
}
}
Сценарий также может содержать другие классы, и пространства имен, но существенным является именно указанный. Класс должен содержать стандартный метод:
public void Execute (ProcessInfo process, PassState passInfo)
В начале исполнения функции, управление будет передано данному методу. Входящие параметры метода содержат ссылки на информацию о процессе (process), и данные о текущем проходе (passInfo). Под проходом в данном случае понимается совокупность данных (контекст), специфических для выполнения данного конкретного экземпляра функции. При повторном вызове функции, эти данные могут измениться.
Функция сценария должна ссылаться на внутренние пространства имен:
· DocsVision.Workflow.Objects – пространство имен, содержащее описания структур данных карточек СУБП (карточка процесса, справочники)
· DocsVision.Workflow.Runtime – пространство имен сервиса СУБП, производящего обработку процессов
· DocsVision.Workflow.Gates – пространство имен стандартных шлюзов (DocsVision и FileSystem)
Для работы с клиентскими объектами DocsVision, необходимо дополнительно указать ссылку на пространство имен DocsVision.Platform.ObjectManager (описание соответствующих объектов приведено в руководстве разработчика DocsVision).
При необходимости использовать внешние системы (напрямую, или через шлюзы), имеется возможность подключить необходимые программные модули на странице свойств функции сценария.
Основные объекты, которыми оперирует функция сценария – это внутренние объекты сервиса СУБП, специфические для исполняемого процесса. К ним относятся переменные процесса, шлюзы, журнал процесса, и др. Необходимые типы данных расположены в пространстве имен DocsVision.Workflow.Runtime.
Класс ProcessInfo содержит данные о текущем выполняющемся процессе, и включает в себя следующие свойства и методы:
· Gates – коллекция шлюзов, входящих в процесс;
· Variables – коллекция переменных процесса;
· Library – ссылка на справочники (библиотека WorfklowObjects);
· ProcessData – ссылка на карточку процесса (библиотека WorfklowObjects);
· ProcessLog – журнал процесса (библиотека WorfklowObjects)
o GetGateByName – получение шлюза с указанным именем;
o GetVariableByName – получение переменной с указанным именем;
o LogMessage – запись информационного сообщения в журнал процесса.
Экземпляр данного класса выступает в качестве входного параметра функции сценария. С его помощью сценарий может оперировать данными процесса.
Для получения конкретных экземпляров переменных или шлюзов рекомендуется использовать методы GetVariableByName и GetGateByName. Корректность выполнения данных методов обеспечивается уникальностью имен шлюзов и переменных в процессе.
6.1.3.2 Разработка бизнес-процессов
Разработаны следующие основные workflow-процессы, реализующие необходимую функциональность:
· Мониторинг новых запросов
· Мониторинг повесток на утверждение;
· Мониторинг утвержденных повесток на рассылку;
· Мониторинг протоколов на утверждение;
· Мониторинг утвержденных протоколов на рассылку.
· Мониторинг утвержденных на заседании запросов
· Мониторинг запросов, отправленных на доработку
· Рассмотрение запроса до заседания
· Утверждение повестки
· Утверждение протокола
· Утверждение и публикация законопроекта
· Отправка законопроекта на доработку
Для взаимодействия с внешними подсистемами процессы используют следующие шлюзы СУБП:
· Шлюз к файловой системе;
· Шлюз к Exchange;
· Шлюз к SharePoint 2007.
В последующих подразделах описываются действия, выполняемые данными основными процессами.
Мониторинг новых запросов
Процесс ожидает появления нового объекта в библиотеке портала Библиотека Запросов. При появлении нового Запроса, процесс запускает подпроцесс обработки запроса. Графическая схема процесса представлена на рисунке 12.
Рис.12. Мониторинг новых запросов
Функция мониторинга To find a new Request настроена на обнаружение новых объектов библиотеки. Функция подпроцесса запускает подпроцесс «Рассмотрение запроса до заседания» для каждого нового объекта и возвращает управление функции мониторинга.
Рассмотрение запроса до заседания
В рамках процесса осуществляется рассмотрение и согласование нового Запроса.
От родительского процесса в подпроцесс передается ссылка (URL) на новый элемент библиотеки портала.
Процесс извлекает файл запроса: файл электронной формы (XML документ). С формы считывается необходимая информация (номер запроса, тема, министерство и другие), меняется состояние запроса.
Процесс подготавливает и отправляет письма с указанием данных по запросу:
· Письмо автору запроса об успешной регистрации запроса и его запуске в обработку.
· Письмо в Юридический департамент Канцелярии о необходимости рассмотреть новый запрос.
В теле писем указан адрес (URL) Запроса.
После отправки писем процесс ждет завершения рассмотрения запроса в Юридическом департаменте. Для этого используется стандартная функция мониторинга библиотеки портала. Функция периодически (один раз в час) опрашивает элемент библиотеки портала на предмет изменения определенного поля электронной формы на необходимое значение. Как только поле будет изменено (одним из сотрудников Юридического департамента), функция передаст управление дальше.
Процесс считывает обновленные данные формы, формирует письмо с результатами согласования Юридического департамента и направляет письмо в Организационный департамент Канцелярии.
Схема работы процесса представлена на рисунке 13.
Рис.13. Рассмотрение запроса до заседания
Процессы мониторинга
· Мониторинг повесток на утверждение;
· Мониторинг утвержденных повесток на рассылку;
· Мониторинг протоколов на утверждение;
· Мониторинг утвержденных протоколов на рассылку.
· Мониторинг утвержденных на заседании запросов
· Мониторинг запросов, отправленных на доработку
Процессы мониторинга библиотек документов портала построены единообразно.
Процесс ожидает появления в указанной для него библиотеке документов элемента, удовлетворяющего заданным условиям. При появлении такого элемента меняется состояние элемента и запускается подпроцесс его обработки.
Схема работы процесса представлена на рисунке 14.
Рис.14 Процессы мониторинга
Отправка законопроекта на доработку
В рамках процесса осуществляется передача запроса на доработку в подготовивший его орган власти и отслеживание возврата с доработки.
Данный процесс автоматически запускается для запросов с состоянием «К отправке на доработку». Это состояние запрос приобретает или по результатам рассмотрения его на заседании Правительства, или по решению Организационного департамента.
Процесс считывает данные запроса и определяет причину отправки на доработку. В зависимости от причины формируется необходимое письмо в министерство с просьбой доработать запрос.
Поскольку министерство может не иметь доступ к запросу, хранимому на портале Канцелярии, процесс прикладывает к письму файл проекта нормативного акта и файл заключения по запросу.
Для контроля возврата запроса с доработки процесс направляет задание сотруднику Организационного департамента.
После отправки письма в Министерство и задания в Организационный департамент процесс ждет возврата запроса с доработки.
Когда доработанный запрос будет передан Министерством в Канцелярию правительства. Сотрудник Организационного департамента должен прикрепить к запросу новую версию проекта нормативного документа и проставить отметку о возврате запроса с доработки.
Процесс запустит новый цикл рассмотрения проекта нормативного документа.
Схема работы процесса представлена на рисунке 15.
Согласование повестки/утверждение протокола заседания
Поскольку согласование повестки заседания и утверждение протокола заседания осуществляются по одному маршруту, для этих процессов используется один шаблон процесса. При запуске экземпляра процесса по объекту, родительский (запускающий) процесс передает подпроцессу информацию о том, какой объект рассматривается: повестка или протокол.
В рамках процесса сначала формируется и направляется задание на согласование объекта в Юридический департамент, после того, как юридический департамент согласовал повестку или протокол, направляется задание на согласование и подписание объекта в Организационный департамент.
Рис.15 Отправка законопроекта на доработку
Содержание задания зависит от рассматриваемого документа.
Схема работы процесса представлена на рисунке 16.
Рис.16 Согласование повестки/утверждение протокола заседания
Утверждение и публикация законопроекта
В рамках процесса осуществляется подготовка утвержденного на заседании правительства проекта нормативного акта к публикации и его публикация в официальных изданиях и на портале Правительства Грузии.
Процесс автоматически запускается для запросов с состоянием «Утвержден на заседании правительства»
Шаг 1. Проект запроса направляется в Юридический департамент для сбора итоговых замечаний по тексту документа.
Шаг 2. Запрос с замечаниями юристов направляется в Организационный департамент, где текст документа редактируется в соответствие с замечаниями юристов.
Шаг 3. Запрос снова направляется процессом в Юридический департамент. Сотрудники юридического департамента формируют итоговую версию документа для публикации и прикладывают ее к электронной форме запроса. Также в форме запроса проставляется виза Юридического департамента.
Шаг 4. Итоговая версия документа проходит визирование в электронном виде у Начальника Канцелярии Правительства и у Премьер-министра.
Шаг 5. Итоговая версия документа с визами юридического департамента, Начальника Канцелярии и Премьер-министра публикуется на портале Правительства Грузии, отсылается в официальные издания для публикации, а также всем заинтересованным лицам.
Шаг 5. Состояние запроса на портале меняется на «Утвержден и опубликован»
Схема работы процесса представлена на рисунке 17.
Рис.17 Утверждение и публикация законопроекта
6.2 Разработка инструмента локализации форм
Решение разрабатывалось на русском языке, но так как оно было предназначено для грузинского правительства, необходимо было предоставить средство локализации форм InfoPath на грузинский язык. Стандартные средства поддержки мультиязычной разработки InfoPath не подходили вследствие своей сложности для заказчика, который должен был локализовывать решение.
Для локализации решения была разработана утилита.
Утилита анализирует файл шаблона формы, который представляет из себя cab –архив файлов-xml, описывающих поля, правила, стили, схемы-данных и остальные параметры шаблона формы.
Утилита предоставляет пользователю полный перечень русскоязычных интерфейсных тегов, найденных в этих файлах в виде таблицы (рис. 18). Во втором столбце таблицы необходимо указать грузинские аналоги представленных слов. По нажатию кнопки, утилита заменит русскоязычные теги на грузинские аналоги (данные в формате UTF8 Unicode)
Рис.18 Форма для локализации решения
Заключение
В данном дипломном проекте была разработана системы автоматизации процедуры подготовки и проведения заседаний Канцелярии правительства Грузии.
Эта система позволила Канцелярии Правительства Грузии осуществлять оперативную подготовку и проведение заседаний Правительства, тем самым повысив прозрачность и скорость выпуска правовых документов.
Система была создана на основе интеграции ряда программных продуктов:
- Microsoft SharePoint Portal Server 2007;
- Microsoft Office InfoPath 2007;
- Microsoft Exchange Server;
- DocsVision 3.6;
Для интеграции была использована парадигма процессного управления, реализованная в автоматизации бизнес-процессов с помощью СУБП системы DocsVision. Благодаря такому подходу была обеспечена максимальная гибкость системы, возможность модификации и расширения функциональности системы с минимальным объемом разработки программного кода. Недостатком такого подхода является более низкое быстродействие в сравнении с вариантом разработки специализированного ПО «с нуля». Однако обеспеченный для данной системы уровень быстродействия оказался приемлемым для поставленной задачи.
В целом, все задачи, поставленные в данном дипломном проекте, были выполнены. В качестве перспектив развития системы можно назвать:
- оптимизацию процедур обработки электронных документов;
- интеграцию с новыми информационными системами;
- расширение возможностей системы за счет новых версий ПО.
Комментариев нет:
Отправить комментарий