Разработка регламентов автоматизации документооборота между Минэкономразвития России и подведомственным федеральным агентством, а также между Минэкономразвития России и федеральным министерством в рамках формирования рекомендаций по организации управления внедрением ИКТ на уровне отдельных органов государственной власти (стр. 4 )

Модуль выгрузки объекта

Инициатор: модуль поиска объекта

Алгоритм работы:

1.  Получает на вход коллекцию идентификаторов объектов для выгрузки и идентификатор записи ILSearchRequest. ID.

2.  По ILSearchRequest. ID получает параметры доступа к серверу БД и запрос выгрузки.

3.  В полученный запрос выгрузки добавляется полученная коллекция объектов.

4.  Каждый объект выгружается в XML-описание.

5.  Модулю работы с транспортом отдается XML и ILSearchRequest. ID.

Модуль работы с транспортом

При отправке через модуль транспорта:

1.  Получает коллекцию XML и ILSearchRequest. ID и тип (объект или файл)

2.  Для каждого выгруженного объекта осуществляется преобразование на основании заданного XSLT.

3.  Формируется пакет вида:

<Packet>

<Packet_ID>

<Correspondent_ID>

<Type>

<XML>

</Packet>

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

Прием данных из модуля транспорта:

1.  Обращается к очереди входящих сообщений

2.  Получает пакеты вида

<Packet>

<Packet_ID>

<Correspondent_ID>

<Type>

<XML>

</Packet>

3.  Для каждого пакета осуществляется поиск файлов, связанных с этим пакетом

Модуль загрузки РК

1.  Получает на вход РК.

2.  Для нужных тэгов осуществляет поиск в таблице замещения.

3.  Если в таблице замещения нет нужных записей обращается к нужному справочнику СЭДО.

4.  После преобразования загружает РК в систему или помещает в очередь конфликтов с указанием причин конфликта.

5.  После загрузки РК загружаются связанные с ней файлы.

По итогам загрузки в таблицу полученных объектов заносится новая запись об этом объекте.

4.2.25.2.2  Подсистема транспорта

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

Отправка пакетов включает следующие операции:

·  заполнение очереди отправки;

·  ведение очереди отправки пакетов;

·  ведение общего списка контрагентов, участвующих в обмене информацией с параметрами передачи;

·  поддержка различных видов транспорта для передачи информации;

·  журналирование отправки пакетов;

·  отслеживание отправки и доставки с передачей информации о доставке по тому же каналу передачи;

·  поддержка заданного количества итераций при отправке пакетов корреспондентам.

Прием пакетов включает:

·  чтение очереди приемки пакетов;

·  ведение очереди приемки пакетов;

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

·  журналирование приема пакетов;

·  отправка подтверждения о доставке отправителю;

·  ведение статуса обработки и статуса квитирования.

Для реализации указанных выше функций предлагается архитектурное решение, приведенное на рисунке.

Рис. 4.3.

Работа модулей организована следующим образом:

Отправка объекта

1.  Внешний источник (компонент выгрузки объекта) кладет предварительно сформированное XML-описание объекта для отправки в очередь отправки средствами DataAccessManager.

2.  Вин-сервис транспорта по заданному расписанию вызывает OutboxManager.

3.  OutboxManager средствами DataAccessManager получает коллекцию объектов для отправки.

4.  Затем OutboxManager, для каждого объекта по корреспонденту, через DataAccessManager, получает параметры используемого транспорта.

5.  Для каждого объекта вызывает клиентский модуль нужного транспорта, которому передаются данные для отправки, после этого статус объекта в базе интеграции изменяется.

Получение объекта

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

2.  Найденные объекты отдаются InboxManager.

3.  InboxManager проверяет тип объекта.

4.  Если это служебное сообщение (сообщение о доставке), то через DataAccessManager изменяет статус доставки у пакета с соответствующим идентификатором.

5.  Если это объект, то через DataAccessManager он заносится в очередь входящих, а в очередь исходящих кладется служебное сообщение о доставке пакета с указанным идентификатором.

6.  Внешний сервис загрузки объектов через DataAccessManager выбирает полученные объекты и производит их дальнейшую обработку.

4.2.35.2.3  Подсистема администрирования

Данный раздел описывает реализацию администрирования системы интеграции (СИ). Подсистема должна давать возможность для выполнения следующих функций:

·  настройка таблицы замещения;

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

·  настройка списка адресатов/корреспондентов;

·  настройка поисковых запросов на выгружаемые объекты;

·  просмотр событий системы, фильтрация по различным признакам, очистка журнала;

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

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

·  ведение справочника видов транспорта;

·  ручное редактирование элементов очередей;

·  настройка параметров работы подсистем: параметры соединения с БД, параметры настройки на шлюзы.

Логирование событий осуществляется с помощью LogModule, который реализует методы записи в журнал, а также метод получения записей. В лог-журнале должны присутствовать следующие данные:

·  EventType – тип записи журнала (Ошибка, Информационное, Предупреждение);

·  Level – уровень обработки (наименование модуля-источника записи);

·  ObjectType – тип объекта, если это модуль загрузки, то РК или КЗ или Запрос, если транспорт, то Пакет, либо служебный;

·  Correspondent – адресат;

·  Operation – операция;

·  DateTime – время записи;

·  ObjectTypeObjectDigest – дайджест объекта;

·  Description - текст сообщения.

Функции настройки и просмотра параметров СИ реализуются через пользовательский интерфейс администратора.

4.35.3  Требования к видам обеспечения

4.3.15.3.1  Требования к математическому обеспечению

Не предъявляются.

4.3.25.3.2  Требования к информационному обеспечению

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

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

Информационный обмен между модулями объектов автоматизации в рамках Системы должен осуществляться путем передачи информационных массивов и/или сообщений между объектами автоматизации.

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

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

·  справочник состояний отправки\доставки данных;

·  справочник корреспондентов;

·  справочник видов транспорта;

·  справочник адресатов;

·  справочник XSLT-преобразований;

·  справочник типов объектов;

·  справочник используемых программных модулей.

Состав и содержание справочников может уточняться в ходе проектирования.

В Системе должна использоваться только реляционная система управления базами данных (РСУБД), поддерживающая технологию «клиент-сервер».

Процесс передачи данных в Системе определяется должностными инструкциями штатных сотрудников подразделений объектов автоматизации и нормативно-техническими документами организации Заказчика.

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

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

Процедуры резервного копирования и программная поддержка источников бесперебойного питания должны обеспечиваться средствами сетевого программного обеспечения и СУБД.

Система должна вести журналы регистрации всех выполненных действий, связанных с изменением информации.

4.3.35.3.3  Требования к лингвистическому обеспечению

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

Интерфейс пользователя должен отвечать следующим требованиям:

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

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

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

4.3.45.3.4  Требования к программному обеспечению

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

·  Операционная(ые) система(ы);

·  СУБД;

·  Прикладные программы;