Разработка общесистемных функциональных решений для автоматизированной системы Федерального Казначейства

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

Факт, время и общий результат завершения обработки отражается в журнале соответствующей записью.

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

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

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

Алгоритм журналирования и выборки в виде протоколов представлен на Рис. 10. Темным цветом показан участок журналирования, а белым процесса формирования и доведения протоколов.

Рис. 10. Алгоритм журналирования и формирования протоколов обработки

Доведение протокола означает, что пользователю OEBS становятся доступными для просмотра соответствующие разделы журналов документа по нужным пользователю документам. С помощью инструмента Oracle XML Publisher пользователь может сформировать отчет в нужном ему формате (PDF, XML, HTML, TXT).

Синхронизация между подсистемами.

Проектируемая АСФК является в высокой степени территориально-распределенной системой. Это означает следующее:

Система будет состоять из 90 аппаратно разделенных экземпляров системы, каждый из которых включает СУБД и сервер приложений. Планируется, что эти экземпляры будут взаимодействовать с подсистемой ЦАФК и друг другом посредством online.

Наличие подсистем, функционирующих в offline режиме (Система удаленного финансового документооборота)

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

Документы системы.

Справочная информация.

Настройки системы.

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

Синхронизация изменений атрибутов.

Синхронизация статуса обработки.

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

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

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

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

Для передачи данных из одной подсистемы АСФК в другую используется формат XML. Основные причины использования XML заключаются в следующем:

Является стандартом и многие стандартные программные средства «заточены» на обработку XML.

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

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

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

Заключение

автоматизированный пользовательский межсистемный идентификатор

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

В рамках данной работы представлены следующие результаты, полученные при активном участии автора во время работы на проекте по созданию АСФК:

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

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

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

Список литературы

1. Бюджетный кодекс Российской Федерации (в редакции 02 февраля 2006 г.) N 145-ФЗ.

2. Пресс-релиз компании Оракл «Федеральное казначейство Российской Федерации и Oracle подписали контракт на разработку и внедрение автоматизированной системы для Федерального казначейства» // Москва, январь 2006.

3. К. Панов «DocFlow и ERP: интегрировать или достраивать?» // IKS-online No 9. 2006.

4. М.А. Тарасов «Кассовое обслуживание бюджетов. От конфликта к дискуссии», журнал «Бюджет», 02.2004.

5. Т.Г. Нестеренко «Роль Федерального Казначейства в реформировании бюджетного процесса» // РИА «РосБизнесКонсалтинг», 2006.

6. Университетская информационная система «Россия» «Бюджетная система Российской Федерации».

7. Положение о Федеральном Казначействе (в ред. Постановления Правительства РФ от 11.11.2006 N 669).

8. Г.С. Поспелов «Искусственный интеллект - основа новой информационной технологии» // Москва, «Наука» 1988.

9. Доклад по итогам за 2006 год «О деятельности Управления Федерального Казначейства» // Управление Федерального Казначейства Брянской области.

10. Пресс-релиз Федерального Казначейства «Федеральное казначейство информирует о завершении первой стадии проекта по разработке и внедрению автоматизированной системы Федерального казначейства» // 2006.

11. И.П. Беляев, В.М. Капустян «Процессы и концепты» // Москва, 1997.

12. Саидов-Лебединский О.З. «Пособие по освоению методики внедрения готовых приложений на основе методики Oracle AIM».

Размещено на Allbest.ru