Разработка системы автоматизации процедуры подготовки и проведения заседаний Правительства с помощью технологий Microsoft – Часть 4 (Реализация системы)

6.3 Web-портал

6.3.1 Продукт Microsoft SharePoint Portal Server 2007

Для обеспечения хранения и доступа ко всем объектам и справочникам системы предусмотрено использование Microsoft SharePoint Portal Server 2007.

Данный продукт предназначен для реализации web-порталов предприятий, хранения и обеспечения разноуровневого доступа к информации. Портал, построенный на основе Microsoft SharePoint Portal Server 2007, обеспечивает публикацию файлов различных форматов, списочной информации. Обеспечивается возможность структурирования информации, поддержки версионности документов, гибкие возможности поиска.

Выбор данного продукта для реализации web-портала был обусловлен следующими причинами:

· Возможность построения структуры портала без написания программного кода.

· Удобные инструменты создания и управления архивом документов.

· Встроенная система авторизованного входа на портал.

· Гибкая система разграничении прав доступа.

· «Тонкий клиент» - возможность доступа к документам портала через Web-броузер, в том числе по сети Internet.

6.3.2 Структура web-портала

На SharePoint портале реализована следующая функциональность системы:

1. Электронный архив документов, с возможностью разграничения прав доступа на уровне контейнера и объекта (документа):

· Архив проектов нормативных актов.

· Архив повесток и протоколов заседаний.

· Архив повесток и протоколов предварительных совещаний.

· Архив опубликованных документов.

2. Встроенные возможности MOSS обеспечивают гибкий атрибутивный и полнотекстовый поиск хранимых документов, а также возможность группировки результатов поиска по различным атрибутам.

3. Автоматическая версионность хранимых документов.

4. Планирование проведения заседаний правительства в календаре MOSS.

5. Ведение справочников:

· Справочник министерств с контактной информацией;

· Список руководства законодательных и исполнительных органов Грузии с контактной информацией;

· Департаменты канцелярии и контактная информация;

· Список заграничных посольств в Грузии и Грузинских посольств за границей, с контактной информацией;

· Типы нормативных актов;

· Список рассылки.

Физическая структура портала представлена на рисунке 8.

Рис. 8. Физическая структура web-портала

На рисунке представлены объекты SharePoint, созданные в рамках разработанного решения. Стандартные разделы портала SharePoint и стандартные объекты (страницы, списки, библиотеки документов и пр.) на рисунке не представлены.

6.3.3 Главная станица портала

Центром навигации портала является главная страница портала, которая содержит ссылки на все общие разделы портала, на ней публикуются внутренние новости Канцелярии правительства.

6.3.4 Библиотека запросов министерств

Это библиотека форм портала. Каждый создаваемый элемент является электронной формой (форма InfoPath), созданной по строго определенному шаблону.

В библиотеке хранятся все запросы на рассмотрение проекта нормативного акта, полученные от министерств.

Сотрудники министерств имеют доступ к библиотеке на основе выделенной для каждого министерства учетной записи. Они могут создавать новые документы и видеть статус прохождения документов только своего министерства.

Сотрудники юридического и организационного отдела Канцелярии, а также главы министерств и Премьер-министр имеют доступ на чтение ко всем хранящимся документам.

По умолчанию в библиотеке отображается следующая информация:

· Номер запроса;

· Ссылка на форму запроса;

· Дата создания запроса;

· Министерство;

· Состояние выполнения запроса.

Перечень отображаемых полей может быть изменен настройками представления MOSS.

6.3.5 Библиотека повесток/протоколов заседаний

Это библиотека форм портала. Каждый создаваемый элемент является электронной формой (форма InfoPath), созданной по строго определенному шаблону.

В библиотеке хранятся все повестки/протоколы проведенных или планируемых заседаний Правительства.

Сотрудники юридического и организационного отдела Канцелярии, а также главы министерств и Премьер-министр имеют доступ на чтение ко всем хранящимся документам

Ответственный за организацию проведения заседаний сотрудник Канцелярии имеет доступ на редактирование документов и создание новых документов.

6.3.6 Библиотека повесток/протоколов совещаний

Это библиотека форм портала. Каждый создаваемый элемент является электронной формой (форма InfoPath), созданной по строго определенному шаблону.

В библиотеке хранятся все повестки/протоколы проведенных или планируемых предварительных совещаний.

Сотрудники юридического и организационного отдела Канцелярии, а также главы министерств и Премьер-министр имеют доступ на чтение ко всем хранящимся документам

Ответственный за организацию проведения заседаний сотрудник Канцелярии имеет доступ на редактирование документов и создание новых документов.

6.3.7 Библиотека опубликованных документов

В библиотеке автоматически размещаются утвержденные на заседании Правительства и подписанные Премьер-министром нормативные акты.

К библиотеке возможен неавторизованный доступ через сеть Internet с правом на чтение документов.

6.3.8 Web-службы, развернутые на портале

Web-служба — программная система, чьи общедоступные интерфейсы определены на языке XML. Веб-службы обеспечивают взаимодействие программных систем независимо от платформы.

Для реализация задачи на портале были развернуты две Web-службы, написанные на языке C#.

1. Web-служба для автоматического формирования повестки заседания.

Служба используется в качестве источника данных для формы InfoPath Повестки заседания. Служба формирует структурированный набор информации по тем запросам от министерств, находящимся в Системе, которые должны или могут быть включены в повестку ближайшего заседания.

Входные параметры службы:

· Библиотека запросов – URL библиотеки портала, где хранятся запросы министерств.

· Согласованные запросы – массив строк, перечень состояния запросов. Запросы с этими состояниями должны быть автоматически включены в Повестку. («Вынесен на заседание. Согласован», «Вынесен на заседание. Не согласован»)

· Обработанные запросы- массив строк, перечень состояний запросов. Запросы с этими состояниями могут быть включены в повестку дополнительно. («На экспертизе в ЮД», «Получен паспорт», «Вынесено заключение», «Перенесен с заседания»)

Результатом работы службы в каждый момент времени является XML-структура с набором информации о тех запросах из Библиотеки запросов, состояния которых попадают в массивы Согласованные запросы или Обработанные запросы. Причем, в итоговой XML-структуре по каждому запросу имеется атрибут, указывающий попадает ли его состояние в массив Согласованные запросы.

Стандартные возможности InfoPath позволяют подключить результат работы Web-службы в качестве источника данных для заполнения полей формы.

В электронной форме повестки заседания на создание формы прописан Java-код, который работает с указанным источником данных.

При создании новой формы перебираются запросы, попавшие в выборку Web-службы, и если запрос имеет атрибут, указывающий, что его состояние попадает в массив Согласованные запросы, то в форму автоматически добавляется информация по этому запросу (URL на форму запроса на портале, номер, министерство, название, состояние).

Пользователь системы, имеющий соответствующие права может удалить автоматически внесенную информацию.

Запрос, чье состояние попало в массив Рассмотренные запросы может быть включен в повестку пользователем системы при помощи выпадающего списка. В списке отображаются только отобранные Web-службой запросы. При выборе запроса, информация о нем (URL на форму запроса на портале, номер, министерство, название, состояние) будут размещены в форме java scripting -кодом.

2. Web-служба для автоматического изменения состояний запросов

На заседании по каждому запросу должно быть принято решение (резолюция). Решения фиксируются в форме протокола заседания. После того как протокол заседания утвержден и бумажная версия подписана председателем заседания, в Системе необходимо изменить состояния всех рассмотренных на заседании вопросов в соответствие с вынесенными резолюциями.

Изменение состояний реализовано при помощи Web-службы. На вход службы подается сформированный кодом формы XML с информацией о рассмотренных запросах и вынесенных по ним решениям. Web-служба находит в библиотеке запросов нужные и меняет XML запросов, изменяя старое состояние на новое.

6.4 Реализация алгоритмов обработки электронных документов

6.4.1 Автоматизация бизнес-процессов на основе модели Workflow

Парадигма Workflow-системы – это «поток (элементов) работ». В ней любую деятельность можно представить в виде элементов работы, продвигающихся по определенному маршруту между исполнителями в соответствии с заданными правилами. При этом от одного исполнителя к другому передается точка управления. Данная парадигма легко представима в виде графа, что позволяет проводить автоматизацию визуальными средствами без использования традиционного программного кода или с минимальным его использованием.

Использование для реализации бизнес-логики Workflow-системы позволяет получить ряд преимуществ:

· высокая надежность, обеспечиваемая архитектурой сервера исполнения процессов (состояние процессов сохраняется в базе данных и не зависит от возможного перезапуска сервера);

· возможность отладки процессов и устранения ошибок во время выполнения;

· возможность мониторинга состояния процессов;

· возможность модификации бизнес-логики процесса с минимальным объемом разработки программного кода.

Описанные преимущества получаются ценой некоторого снижения быстродействия по сравнению с использованием специально разработанного монолитного приложения (при большой загрузке сервера исполнения процессов документ может обрабатываться до нескольких минут). Однако такое снижение быстродействия в данном случае является допустимым.

6.4.2 Автоматизация бизнес-процессов на платформе DocsVision 3.6

Платформа DocsVision 3.6 и приложение «Управление процессами» (СУБП) представляют собой систему описания сложных процессов обработки информации в организации и полнофункциональный Workflow сервер. СУБП является решением на основе платформы DocsVision 3.6, предназначенным для создания бизнес-процессов любой сложности и управления ими.

Ключевыми объектами в терминологии СУБП является бизнес-процесс, переменные процесса, функции, и шлюзы

6.4.2.1 Бизнес-процесс

Бизнес-процесс представляет собой формальное описание бизнес-процесса организации. Формальное описание строится из набора атомарных операций (функций), составляющих процесс, и связей между ними, определяющих порядок выполнения операций. Функции процесса оперируют данными внешних систем с помощью шлюзов, и обмениваются ими через переменные процесса.

Процесс должен обязательно включать в себя специальную функцию, инициирующую выполнение процесса, а также одну или несколько функций, завершающих выполнение процесса. Остальные функции могут быть связаны между собой произвольным количеством связей, которые определяют порядок их выполнения в процессе. Возможно наличие в процессе циклов, условных и безусловных переходов.

Физически, бизнес-процесс состоит из набора данных, хранящихся в БД DocsVision; набора свойств и методов для операций с этими данными; и карточки бизнес-процесса – карточки DocsVision, реализующей пользовательский интерфейс для управления данными процесса.

На рисунке 9 представлен пример бизнес-процесса в интерфейсе дизайнера бизнес-процессов.

Рис.9 Интерфейс редактора процессов.

6.4.2.2 Переменные процесса

Переменные процесса являются субъектами, которыми оперируют функции процесса, и обеспечивают единственный способ обмена информацией между функциями процесса.

Каждая переменная имеет уникальный идентификатор (в формате строки), позволяющий отличить ее от остальных переменных бизнес-процесса; имя; значение (величину или набор данных, которые характеризуют переменную); и отображаемое значение - которое может как соответствовать значению, так и характеризовать переменную для пользователя более явным образом. Например, для переменной, представляющей карточку DocsVision, значением является идентификатор карточки, а отображаемым значением – ее название.

Все переменные являются строго типизированными. К стандартным (системным) типам переменных относятся следующие типы:

· String – строка,

· Integer - целое,

· Double – число с плавающей точкой,

· Boolean – булевское значение,

· DateTime – дата и время,

· Перечисление - при формировании шаблона процесса можно описать поля типа перечисления, и задать все возможные значения. Все значения перечисления в процессе - строковые.

Кроме этих стандартных типов, в процесс могут быть добавлены переменные шлюзов. Каждый зарегистрированный в системе шлюз поставляет собственные типы переменных.

Автоматического преобразования типов не существует, для преобразования экземпляра переменной от одного типа к другому, если таковое возможно, необходимо использовать специальные функции, либо воспользоваться сценарием.

На рисунке 10 представлено окно настроек переменных бизнес-процесса

Рис.10. Окно переменных процесса

6.4.2.3 Функции

Описание процесса содержит набор принадлежащих ему функций, настройки их свойств (свойства функции могут быть проинициализированы как непосредственно значением, так и некой переменной процесса), и описание связей между функциями. Каждая функция имеет собственный набор данных (обычно - в формате XML), где хранятся настройки функции, и любые дополнительные данные.

Функции, и связи между ними, могут иметь собственные названия и описания для улучшения читаемости бизнес-процесса.

Функция может быть как независимой (выполняться без взаимодействия с внешними системами), так и привязанной к одной или нескольким внешним системам при помощи шлюзов. Привязка к шлюзам декларируется функцией на программном уровне, и проверяется на этапе добавления функции в процесс.

На рисунке 11 представлена функция обмена данными и диалоговые окна настройки функции

Рис. 11 Окно настройки функции

6.4.2.4 Шлюзы

Шлюз представляет собой совокупность программных компонент, предназначенных для обеспечения взаимодействия СУБП с внешними системами. Основные функции шлюза:

· Обмен данными между прикладной системой и СУБП

· Маршрутизация ссылки на объект прикладной системы в функциях СУБП

· Специализированная обработка прикладного объекта в рамках процесса

Также шлюзы предоставляют свой набор типов переменных, которыми можно оперировать в СУБП наряду с обычными переменными. Под типами переменных подразумеваются все возможные виды объектов, которыми может оперировать шлюз. Например, шлюз к файловой системе оперирует двумя типами объектов – файлами, и папками файловой системы. Соответственно, данный шлюз предоставляет бизнес-процессам два типа переменных – “Папка файловой системы” и “Файл файловой системы”.

Выбор механизма использования уникальных значений и отображаемых значений переменных, поставляемых конкретным шлюзом, выбирается разработчиком этого шлюза. Например, в рассмотренном выше шлюзе к файловой системе, в качестве уникальных значений использованы полные физические пути к файлам и папкам, а в качестве отображаемых значений – их частичные имена.

6.4.2.5 Сценарии

Сценарии представляют собой мощный механизм расширения функциональности СУБП, используемый в тех случаях, когда требуемые действия слишком сложно (или невозможно) выполнить при помощи стандартных функций.

Типовые применения сценариев следующие:

· преобразование типов и форматов данных;

· динамическое изменение данных процесса во время его работы (добавление и удаление переменных процесса; изменение значений переменных);

· сложные операции обработки данных, которые невозможно осуществить стандартными средствами (например, работа со справочниками и специфическими карточками DocsVision);

· взаимодействие с внешними системами (не предусмотренное функциями или шлюзами этих систем);

Функция сценария (Script) позволяет выполнить в рамках процесса произвольный код на языке платформы .NET (C# или VB.NET).

6.4.2.6 Разработка бизнес-процесса

Разработка бизнес-процесса на базе приложения WorkFlow платформы DocsVision 3.6 включает следующие этапы:

1. Составление спецификации на бизнес-логику автоматизируемого процесса

Пример бизнес - логики:

1. Принять факс c почтового ящика

2. По номеру отправителя, указанному в теме, определить контрагента

3. Создать в системе регистрационную карточку факса, с указанием даты создания, контрагента, автоматически выданным номером

4. отправить задание секретарю на рассмотрение нового факса.

2. Выстроить в дизайнере бизнес-процессов необходимую последовательность функций и связей между ними для реализации бизнес-логики. На этом уровне появляется много «технических функций» работы с данными, не связанных непосредственно с логикой процесса.

Пример: извлечь данные из письма, выделить номер, назначить права.

3. Создать необходимые для настройки функций и обмена данными между ними переменные бизнес процесса.

Пример переменных: Почтовое сообщение, Карточка факса, Почтовое вложение, Секретарь, Контрагент, Название факса.

4. Настроить отдельно каждую функцию, с указанием входных, выходных переменных при помощи диалогового окна настройки, индивидуального для каждого вида функции.

5. Если стандартных функций и функций шлюза не хватает для реализации бизнес-логики процесса, необходимо разработать сценарии на C# или VB.NET.

6. Отладка процесса. Тестирование процесса на тестовых данных. Сообщения об ошибках работы функций регистрируются в журнале экземпляра бизнес-процесса. Конкретный экземпляр процесса может задействовать не все ветки настроенного шаблона бизнес-процесса (например, если контрагент не найден, то функция записи контрагента в карточку не получит управление). Во время отладки необходимо протестировать все возможные варианты прохождения процесса.