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

6. Реализация системы

6.1 Аппаратная реализация системы

Для обеспечения работы системы требуется следующий набор аппаратных серверов:

· Сервер MOSS;

· Сервер DocsVision;

· Сервер баз данных;

· Сервер электронной почты.

Сервер MOSS предназначен для организации работы web-портала. На нем работают Microsoft Office SharePoint Server

Сервер DocsVision обеспечивает работу сервера хранилища DocsVision, а также работу сервера WorkFlow.

Сервер баз данных обеспечивает работу Microsoft SQL Server 2005, на котором располагается база данных DocsVision и база данных Microsoft Office SharePoint Server .

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

Требования к аппаратным ресурсам перечисленных серверов представлены в таблице 4.1.

Таблица 4.1 – Требования к аппаратным ресурсам серверов системы

Назначение	Параметры
Сервер DocsVision	Процессор – 2 процессора на платформе x86, не ниже 2.4 GHz; ОЗУ - 2 GB, с контролем четности; ПЗУ - 72 GB, не ниже 10000 об/мин.
Сервер СУБД	Процессор – 2 процессора на платформе x86, не ниже 2.4 GHz; ОЗУ - 2 GB, с контролем четности; ПЗУ - 200 GB, не ниже 15000 об/мин.
Сервер электронной почты	МП: 2 процессораx86, 2.4 GHz ОЗУ: 2 GB НЖД: 72 GB, 10000 rpm
Сервер MOSS	Процессор – 1 процессор на платформе x86, не ниже 2.5 GHz; ОЗУ – 2GB , минимум – 1GB; ПЗУ - 3 GB минимум, не ниже 7200 об/мин

6.2 Реализация объектов Системы – формы InfoPath.

6.2.1 Продукт Microsoft Office InfoPath 2007

В качестве средства построения электронных форм используется Microsoft Office InfoPath 2007. При этом для каждого вида документов необходимо создать шаблон формы, который будет размещен на web-портале в библиотеке шаблонов форм.

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

Для создания более гибких и мощных интеллектуальных форм предусмотрено использование языков программирования: Visual C# , Microsoft Visual Basic .NET, Java-scripting.

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

Выбор InfoPath в качестве средства разработки объектов системы, позволил решить следующие задачи:

· Создание и изменение форм электронных документов должно быть доступно сотрудникам Канцелярии, не имеющим высокой квалификации в разработке ПО.

· Увеличение скорости разработки без уменьшения надежности.

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

В формах реализованы следующие функциональные возможности:

· Автоматическое заполнение полей из подключенных информационных ресурсов: справочников портала, Web-служб.

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

· Обязательность заполнения полей для сохранения запроса, в том числе обязательность прикрепления документов.

· Разграничение прав доступа на уровне разделов и отдельных полей в зависимости от состояния формы и работающего с ней пользователя.

Основными объектами разрабатываемой системы являются:

1. Запрос – это обращение органов государственной власти в Канцелярию правительства с просьбой рассмотреть проект правового документа на заседании правительства.

2. Повестка совещания/заседания. Повестка подготавливается для каждого заседания (предварительного или заседания правительства). Повестка представляет собой перечень Запросов, которые должны быть рассмотрены на заседании. Чтобы запрос мог быть включен в повестку, он должен пройти предварительное согласование в Канцелярии. Сама повестка до заседания также должна быть согласована и утверждена Начальником канцелярии.

3. Протокол совещания/заседания. Протокол заседания, в котором фиксируются решения по каждому рассмотренному Запросу. Протокол подготавливается после заседания Организационным департаментом. Протокол должен пройти согласование и утвержден у председателя заседания.

6.2.2 Форма Запроса.

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

Рис.4 Форма запроса

Реализованные функциональные возможности:

· Регистрация запроса осуществляется с Web-портала;

· Зарегистрированный запрос публикуется в определенном разделе Web-портала (Библиотека запросов);

· Запрос представляет собой форму InfoPath 2007 и содержит следующие обязательные функциональные поля:

Входящий номер	Регистрационный номер	Заполняется автоматически на основе информации о последнем свободном номере, хранимой на портале
Исходящий номер	Номер, присвоенный запросу департаментом делопроизводства	Заполняется вручную
Название	Название проекта правового акта	Заполняется вручную
Министерство	Министерство – инициатор правового акта	Выбирается из списка, список формируется на основе справочника портала
Отправитель	Ответственное за проект лицо министерства	Выбирается из списка. Список формируется на основе справочника портала и зависит от выбранного значения поля №4
Дата регистрации	Дата создания формы	Заполняется автоматически
Дата запроса	Дата поступления запроса в Канцелярию	Заполняется вручную
Состояние	Состояние запроса (показатель этапа обработки)	По умолчанию: Новый запрос. Может быть изменено ответственным сотрудником или Системой
Регистратор	Пользователь, зарегистрировавший запрос	Заполняется автоматически на основе учетной записи пользователя.
Тема	Категория запроса	Выбирается из списка. Список задан статически в форме.
Информационный запрос	Атрибут, указывающий является ли запрос информационным	Заполняется вручную

· Предусмотрено обязательное прикрепление к форме проекта правового документа в виде электронного редактируемого файла.

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

· В форме предусмотрено ведение истории работы с Запросом (смены состояний)

· Решения по Запросу (согласование, утверждение, отправка на доработку, аннулирование и т.д) осуществляются из формы запроса с помощью кнопок (рис.5)

Рис.5 Принятие решений из формы запроса

6.2.3 Форма повестки заседания/совещания

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

Рис.6 Форма повестки

Основными элементами повестки являются четыре повторяющихся таблицы: Согласованные вопросы, Совещательные вопросы, Дополнительные вопросы, Информационные вопросы. Повторяющаяся таблица – элемент управления, таблица, в каждой строке которой содержится одинаковый набор полей, атрибутов.

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

· Название (заполняется автоматически)

· Состояние (заполняется автоматически)

· Министерство (заполнятся автоматически)

· Докладчик (заполняется вручную)

· Регламент (заполняется вручную)

Составлять и редактировать повестку имеет возможность только координатор. После того как повестка составлена и разослана участникам, у координатора также нет возможности изменить повестку, повестка размещается в определенном разделе Web-портала (Библиотека повесток/протоколов).

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

С помощью использования Web-служб (см. раздел 6.3.8) реализована следующая функциональность формы:

В раздел Согласованные вопросы при создании повестки автоматически заносятся запросы с состоянием «Передан на заседание. Согласован», имеющиеся в системе. У координатора есть возможность удалить внесенные автоматически запросы.

В раздел Совещательные вопросы при создании повестки автоматически заносятся запросы с состоянием «Передан заседание правительства. Не согласован» У координатора есть возможность удалить внесенные автоматически запросы.

В раздел Информационные запросы при создании повестки автоматически вносятся запросы, имеющие атрибут Информационный и состояние «Передан на заседание. Согласован», «Передан на заседание. Не согласован».

В раздел Дополнительные запросы координатор из выпадающего списка может добавить запросы с состояниями:

· На экспертизе в ЮД;

· Полечено заключение ЮД;

· Перенесен с заседания;

· Получен паспорт.

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

Из Повестки можно перейти к любому запросу по ссылке.

6.2.4 Форма протокола заседания

Форма протокола заседания является другим видом (view) формы повестки.

Форма протокола представлена на рисунке 7.

Рис.7 Форма протокола

Основные отличия Протокола заседания от Повестки:

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

2. Добавлен раздел вынесения резолюции по каждому запросу

С помощью использования Web-служб (см. раздел 6.3.8) реализована следующая функциональность:

1. Автоматическое формирование Протокола на основе повестки: перенос запросов из повестки (из 4 таблиц) в протокол (в одну таблицу).

2. Автоматическое изменение состояний рассмотренных запросов в системе в соответствие с вынесенными резолюциями после утверждения протокола.

6.2.5 Кодирование форм InfoPath

Формы InfoPath предоставляют достаточно гибкие инструменты создания интерфейсов без кодирования: условное форматирование полей, управление видимостью полей, правилами, ролями, источниками данных.

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

В связи с этим большая часть требуемого функционала в формах была реализована с помощью кодирования на языке Jscript:

Основные доработки функционала форм на основе кода:

1. Автоматическое заполнение полей формы при создании новой формы повестки. Поля заполняются на основе данных (XML структуры) формируемой Web-сервисом. Сервис предоставляет данные о имеющихся на данный момент в системе нерассмотренных запросах министерств. Код формирует из этих данных повторяющуюся таблицу на форме.

2. Возможность сортировки строк повторяющейся таблицы на форме. Пользователь проставляет в специально отведенном столбце таблицы порядковые номера строк, нажимает кнопку Сортировать – и с помощью кода в XML-файле формы в соответствующем порядке переставляются разделы тэгов, описывающие строку повторяющейся таблицы. Изменения (отсортированная таблица) сразу отображаются на форме.

3. Автоматическое формирование формы протокола на основе формы соответствующей повестки. Код считывает данные из 4х однотипных таблиц формы повестки и заполняет одну, сводную таблицу формы протокола.

4. В форме InfoPath существует возможность прикрепить к форме любой файл, но нет возможности предоставить пользователям этот файл только на чтение. Для того, чтобы реализовать эту возможность был разработан компонент Active X. Компонент вызывается из формы InfoPath по кнопке, ему передается содержание файла прикрепленного к форме в формате base64 (формат кодирования бинарных данных в текстовом виде). Active X создает временную копию файла на файловой системе, Таким образом каждый пользователь работает со своей копией приложенного к форме файла, оригинал файла им недоступен для редактирования.

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

6. Ведение истории работы с формой. При наступлении определенных событий, заполняется таблица истории формы: событие, пользователь, дата события.

7. Формирование набора данных в виде XML на основе данных формы для последующей передачи XML web-сервису, отбирающему на основе этих данных объекты для изменения на портале.