Аннотация (стр. 6 из 8)

2) Учетные данные – преобразованные первичные данные в рамках операции «Регистрация»

Для обеспечения целостности системы, а также для связи учетных и первичных данных было принято решение – все актуальные документы АСФК в рамках одного экземпляра системы регистрировать и хранить в центральной таблице «Реестр документов». Запись в таблице «Реестр документов» характеризует один документ системы и называется «Карточка документа».

Карточка документов содержит основную техническую информацию о документе и связана (путем использования ссылок на неё) как с первичными документами, так и с учетными данными по ним. Карточка документов включает основные атрибуты документов такие, как:

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

- Ключ и имя таблицы первичных документов

- Ключ и имя таблицы учетных документов

- Бизнес-статус – характеризует стадию жизненного цикла документа

- Статус утверждения – характеризует состояние документа относительно процесса утверждения

- Статус перехода – характеризует состояние документа относительно процесса передачи из одной подсистемы АСФК в другую.

Предполагается, что в таблице «Реестр документов» будет одновременно храниться около 10⁷ записей. При существующих программно-аппаратных средствах не представляет особой проблемы обеспечить приемлемое время отклика при выборке данных. В частности, предлагается использовать такие средства СУБД Oracle 10g, как индексация и партиционирование.

4.3.2 Операции над документами

В разделе 4.2.3 «Анализ возможных средств реализации» было показано, что стандартные средства по обеспечению жизненного цикла документов не покрывают всех требований к АСФК. В связи с этим руководством проекта была поставлена задача – разработать альтернативный механизм, обеспечивающий все базовые функции документооборота в системе. Все автоматизированные бизнес-процессы в рамках АСФК должны работать, используя этот механизм.

Основные преимущества данного механизма по сравнению со стандартными средствами (Oracle Workflow):

- Существенный выигрыш в производительности за счет передачи управления другому участку процесса без обработки списка событий (как в Workflow)

- Возможность настройки логики на трехуровневой архитектуре OEBS. (настройка Oracle Workflow базируется на клиент-серверной архитектуре)

- Отражение бизнес специфики Федерального Казначейства в интерфейсе настроек и простота настройки

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

Схема 5 Алгоритм операционной модели

В рамках операционной модели используются следующие понятия:

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

Шаг операции – элементарная составная часть при настройке операции. Результатом исполнения шага является либо “Success”, либо “Error”. В зависимости от результата выполнения шага, может осуществляться условный переход к другим настроенным шагам операции.

Возможны следующие типы шагов:

- Стандартное действие – шаг операции, в рамках которого выполняется сохраненная в базе данных PL\SQL процедура. Результатом выполнения действия может являться проверка, изменение атрибутов информационного объекта (либо создание новых информационных объектов). Данная процедура не открывает автономных транзакций.

- Проверка – действие, в рамках которого выполняется проверка атрибутов документов системы. Единственным результатом выполнения проверки является подтверждение истинности или ложности логического выражения применимо к проверяемому экземпляру информационного объекта. В случае истинности проверка передает 0, в случае предупредительного контроля 1, в случае блокирующего контроля 2.

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

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

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

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

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

4.3.3 Реализация контроля документов в АСФК

Контроль является одной из основных функцией в деятельности Федерального Казначейства. В тоже время, Контроль – функция, которая в наибольшей степени подлежит автоматизации посредством программных средств. Обеспечение различных видов контроля на разных этапах жизненного цикла документа является одной из приоритетных задач при проектировании АСФК.

На проекте по созданию АСФК выделяют два типа контроля:

1) Автоматический – контроль атрибутов документов, на основании предварительно настроенных правил в системе

2) Пользовательский – контроль осуществляется визуально путем просмотра пользователем данных формы. Пользовательский контроль в АСФК реализован посредством многоуровневого утверждения (см 4.3.4).

В настоящий момент система Oracle E-Business Suite не имеет средств, покрывающих все требования к АСФК по части контроля, а также обеспечивающих единый подход к настройке контроля для всех типов документов системы. В связи с этим группой функциональной архитектуры проекта было принято решение о реализации единой компоненты, обеспечивающей автоматический контроль. Посредством автоматического контроля необходимо обеспечить решение ряда следующих задач:

1) Контроль данных, передаваемых в данный экземпляр OEBS из вне посредством XML файла

2) Контроль полей форм при вводе документов вручную пользователем

3) Контроль полей документов, попадающих в систему посредством сканирования бумажных носителей

4) Контроль атрибутов документов в таблицах системы на разных стадиях жизненного цикла документа в АСФК

Все эти задачи были решены с помощью одной настроечной формы и 10 таблиц с правилами настройки.

Схема 6 Алгоритм автоматического контроля

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

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

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

Контроль – осуществление правила проверки.

4.3.4 Многоуровневое утверждение

Посредством многоуровневого утверждения в системе АСФК реализован пользовательский контроль. Кроме этого данная функциональность интегрирована со средствами электронной цифровой подписи.

В отличие от Операций и Автоматического контроля утверждение выполняется в асинхронном по отношению к пользователю режиме и, следовательно, не предъявляет серьезных требований к производительности. В связи с этим возможно использование ряда стандартных средств, в частности Oracle Workflow, в который встроена компонента по утверждению документов (Approval Management Engine).