Аннотация (стр. 7 из 8)
Тем не менее, специфика проекта накладывает дополнительные ограничения:
1) Необходимость работы с кастомизированными формами
2) Необходимость привязки электронной цифровой подписи к документу
3) Обеспечение правил настройки посредством трехуровневой архитектуры, а не через клиент-сервер.
4) Необходимость интеграции с общим подходом по реализации базовых функций АСФК, который включает в себя Операции, Контроли и др.
5) Отсутствие в системе модуля HR (управление персоналом) для настройки иерархий пользователей в рамках организаций
По этой причине потребовалось обеспечить ряд разработок, касающихся:
1) Вычисления цепочки утверждающих пользователей на основании предварительно настроенных правил
2) Привязку к средствам электронной цифровой подписи
3) Изменение статуса утверждения документа в зависимости от стадии утверждения
4) Интеграция с операционной моделью, которая, в частности, подразумевает автоматический запуск многоуровневого утверждения по окончанию операции
Процесс непосредственного исполнения утверждения реализован посредством стандартных средств и может быть наглядно представлен в виде следующей схемы из Workflow Builder:
Схема 7
4.3.5 Журналирование и формирование протоколов обработки
Не менее важным компонентом является создание подсистемы контроля и учета результатов автоматизированной обработки, обеспечивающей уполномоченных пользователей информацией о состоянии обработки, а также о возникающих в процессе обработки ошибках.
Oracle E-Business Suite имеет встроенные средства для журналирования исполнения в каждой своей компоненте. Основу этих средств составляют пакеты приложения Foundation (базовое). Некоторые из этих компонент (например, механизма стандартных сообщений OEBS) использовалась для создания системы журналирования при кастомизации.
Разработанная подсистема журналирования является встроенной в операционную модель. Процесс журналирования заключается в автоматическом формировании журнала обработки при выполнении автоматической или автоматизированной обработки документов / данных в системе. Журнал обработки состоит из нескольких разделов (субпротоколов), включающих следующую информацию:
- Технические данные о выполнении процедур обработки;
- Ошибки/ предупреждения;
- Результат обработки документа включающий, если это определено для данного типа документа, статус документа в АСФК, информацию, добавленную при обработке (например, регистрационный номер, дату регистрации).
В начале обработки документов / данных в информационном объекте «Журнал обработки документов (Технический протокол)» формируется запись, содержащая основные атрибуты процедуры обработки: тип документа (данных), глобальный системный идентификатор документа, время обработки, данные о пользователе.
В случае, когда обработка предполагает изменение атрибутов объекта, в журнал обработки документа добавляются записи, описывающие выполненные изменения.
Факт, время и общий результат завершения обработки отражается в журнале соответствующей записью.
Удаление (архивирование) данных по журналу обработки документов и сформированным протоколам по документам, относящимся к закрытым периодам, происходит в рамках выполнения процедур архивирования документов и данных. Так же по запросу администратора (уполномоченного пользователя) могут быть отправлены в архив (удалены) журналы обработки по документам и протоколы по документам, которые находятся в конечном статусе (в статусной модели установлен соответствующий атрибут для статуса).
Журналы, полученные в результате обработки, содержат всю информацию, относящуюся к операциям над документам. При этом различным группам пользователей АСФК нужна только информация определенного вида. Например, администратор АСФК заинтересован в техническом аспекте функционирования системы, т.е. ему нужна информация о системных ошибках и уведомлениях. Бизнес пользователь наоборот заинтересован в конечных результатах обработки и для него будут абсолютно неинформативны сообщения в технических терминах. Также немаловажен аспект безопасности, т.е. имеет ли право данный пользователь получать ту или иную информацию по обработке документа.
В связи с этим была создана функциональность, благодаря которой можно было бы гибко и удобно настраивать правила выборки из журналов, а также рассылки полученной выборке в виде отчета заинтересованным получателям.
Алгоритм журналирования и выборки в виде протоколов представлен на Схеме 8. Темным цветом показан участок журналирования, а белым процесса формирования и доведения протоколов.
Схема 8 Алгоритм журналирования и формирования протоколов обработки
Доведение протокола означает, что пользователю OEBS становятся доступными для просмотра соответствующие разделы журналов документа по нужным пользователю документам. С помощью инструмента Oracle XML Publisher пользователь может сформировать отчет в нужном ему формате (PDF, XML, HTML, TXT).
4.3.6 Синхронизация между подсистемами
Проектируемая АСФК является в высокой степени территориально-распределенной системой. Это означает следующее:
1. Система будет состоять из 90 аппаратно разделенных экземпляров системы, каждый из которых включает СУБД и сервер приложений. Планируется, что эти экземпляры будут взаимодействовать с подсистемой ЦАФК и друг другом посредством online.
2. Наличие подсистем, функционирующих в offline режиме (Система удаленного финансового документооборота)
В связи с этим, возникает ряд задач по синхронизации информационных объектов в рамках общей системы. А именно, необходимо обеспечить синхронизацию объектов следующих классов:
- Документы системы
- Справочная информация
- Настройки системы
В данной работе рассматривается только решение задачи по синхронизации документов. Задача по синхронизации возникла в связи с тем, что в различных подсистемах АСФК могут существовать экземпляры одного и того же документа. Данную задачу можно разбить на ряд подзадач:
- Синхронизация изменений атрибутов
- Синхронизация статуса обработки
- Синхронизация журналов обработки – пользователи должны знать все об операциях, проводимых над документом, вне зависимости от подсистемы, в которой та или иная операция была проведена.
- Избежание дублирующей информации – в одной подсистеме может быть не более одного экземпляра документа
- Соблюдение очередности синхронизации – все изменения документов при синхронизации должны осуществляться строго в хронологическом порядке источника изменений
Задачи по синхронизации были решены на базе уже имеющихся программных средств от сторонних разработчиков, обеспечивающих гарантированную доставку сообщений получателю в рамках распределенной автоматизированной системы. Данное решение подразумевает использование единого адресного пространства, т.е. формат адресов получателей стандартизирован в рамках АСФК.
Для передачи данных из одной подсистемы АСФК в другую используется формат XML. Основные причины использования XML заключаются в следующем:
1) Является стандартом и многие стандартные программные средства «заточены» на обработку XML
2) Знаком широкому кругу проектных участников, что позволяет использовать без проведения дополнительного обучения
3) Обеспечивает большую гибкость настройки, что позволяет достичь практически 100% семантического соответствия между документом в формате XML и реальным документом бизнес процесса.
Тем не менее, благодаря своей иногда излишней гибкости XML обладает рядом существенных недостатков по сравнению со стандартами, в которых смысл каждого тэга фиксирован (например, EDI [16]). Самым существенным недостатком является увеличение объемов передачи. Документ в виде XML занимает, по меньшей мере, в три раза больше места, чем такой же документ, представленный в таблице реляционной БД. Также недостатком является необходимость согласования форматов (названий тэгов) всеми участниками проектной команды, что для большого проекта может привести к существенным издержкам.
Проект по созданию территориально-распределенной, многофункциональной, защищенной, автоматизированной системы Федерального Казначейства является наиболее масштабным проектом автоматизации в государственной сфере. Реализация общесистемных программных компонент позволяет существенно упростить и ускорить разработку автоматизированной системы в рамках данного проекта при выполнении всех требований к гибкости настроек, безопасности и производительности.
В рамках данной работы представлены следующие результаты, полученные при активном участии автора во время работы на проекте по созданию АСФК:
1) Составлена нормативная процессная модель деятельности ФК, благодаря которой удалось получить в достаточной степени полный перечень информационных объектов системы (используемых документов) и примерный перечень операций над ними
2) Проведен анализ стандартной функциональности OEBS на предмет покрытия требований к общесистемным функциям обеспечению деятельности в рамках модели, результатом которого стал список расширений для обеспечения базовой функциональности документооборота ФК РФ.
3) Разработаны частные технические задания на расширения и проведен контроль разработки. В результате полученное решение передано в тестирование. После проведения комплексного тестирования планируется осуществить инсталляцию данного решения в рамках OEBS на пилотных проектах.