Конкурсная документация по проведению открытого конкурса № 2010/02-ит на выполнение работ по проекту «Создание интеграционной шины данных фгуп «Гознак»

Вид материала

Конкурс

Содержание Характеристика общей архитектуры Системы Требования к системе Структура и принципы функционирования системы ИС, потребители справочника

Подобный материал:

• Конкурсная документация по проведению открытого конкурса № 2010/01-ит на выполнение, 948.61kb.
• Конкурсная документация по проведению открытого конкурса №21 на выполнение работ, 540.97kb.
• Конкурсная документация, 453.69kb.
• Конкурсная документация по проведению открытого конкурса на право заключения договора, 3090.33kb.
• Конкурсная документация по проведению открытого конкурса на право заключения государственных, 1511.34kb.
• Конкурсная документация по проведению открытого конкурса на право заключения государственных, 2339.27kb.
• Конкурсная документация по проведению открытого конкурса на право заключения контракта, 3950.1kb.
• Конкурсная документация по проведению открытого конкурса на право заключения государственных, 1240.84kb.
• Конкурсная документация по проведению открытого конкурса на право заключения государственных, 2490.16kb.
• Конкурсная документация по проведению открытого конкурса на право заключения государственных, 1191.93kb.

Характеристика общей архитектуры Системы

3.1. ИШД должна иметь распределенную архитектуру и состоять из центрального узла, размещаемого в дирекции Заказчика, и локальных узлов, размещаемых на удаленных филиалах Заказчика. ИС Заказчика подключаются к тому узлу Системы, в котором располагается сама ИС.

Структура Системы представлена на рисунке 1.



Рис. 1 Верхнеуровневая структура

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

3.2.1. Сервис прямого взаимодействия ИС.

3.2.2. Сервис распространения справочников.

3.2.3. Сервис передачи объектов СЭД.

Требования к данным сервисам описаны в разделе 4.7 “Требования к сервисам Системы”.

3.3. Ключевым понятием обмена данными между ИС является сообщение. ИС поставщик данных отправляет в Систему сообщение. Система передаёт сообщение в ИС потребитель данных. В случае отсутствия адаптера ИС потребитель данных запрашивает сообщение из Системы.

3.4. ИШД должна предоставлять доступ к отправке и получению сообщений посредством адаптеров ИС или веб-сервисов ИШД.

4. Требования к системе

   1. Структура и принципы функционирования системы

4.1.1. В соответствии с документом “Интеграционная шина данных. Концепция”, ИШД должна включать в себя следующие подсистемы:

• Подсистема сопоставления классификаторов.
  
• Подсистема передачи сообщений.
  
• Подсистема безопасности.
  
• Подсистема мониторинга.
  
• Подсистема администрирования.
  

Общая структура Системы представлена на рисунке 2.



Рис. 2 Структура Системы в разрезе подсистем

2. Требования к подсистеме сопоставления классификаторов

4.2.1. Подсистема сопоставления классификаторов предназначена для выполнения операционной задачи соответствия кодов объектов из справочников различных ИС при обработке сообщений и преобразовании данных в ИШД. Для каждого справочника подсистема должна вести реестр классификатора.

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

ИС1	ИС2	ИС3	Атрибут1	Атрибут2	…
Код1 в ИС1	Код1 в ИС2	Код1 в ИС3	Значение1	Значение2	…
Код2 в ИС1	Код2 в ИС2	Код2 в ИС3	Значение3	Значение4	…
Код3 в ИС1	Код3 в ИС2	Код3 в ИС3	Значение5	Значение6	…
…	…	…			…

Таб. 1. Пример структуры реестра классификатора.


4.2.3. Подсистема должна обеспечивать следующие функции:

1. Управление реестрами классификаторов.
   
   1. Добавление реестра.
      
   2. Изменение реестра (добавление новых атрибутов).
      
   3. Удаление реестра.
      
2. Организация ролевого доступа к реестрам классификаторов на следующие операции:
   
   1. Добавление новых записей в реестр.
      
   2. Изменение/обновление записей в реестре.
      
   3. Удаление записей из реестра.
      
   4. Подписка на получение изменений реестра.
      
3. Ведение статуса доставки обновлений реестра конечным ИС (подписчикам).
   
4. Поиск записи в реестре по заданному коду.
   

4.2.4. В реестре может храниться агрегированная позиция значения кода объекта. Такая ситуация может иметь место когда код в одной ИС соответствует нескольким различным кодам в другой ИС. Пример: одна ИС классифицирует только объект “блокнот”, а другая – “блокнот пружинный” и “блокнот сшивной”. Если в результате поиска записи в реестре возникает неоднозначность (т.е. на поиск по ключу возвращается результат из нескольких записей), данный случай должен рассматриваться и обрабатываться как конфликтная ситуация.

4.2.5. Тип хранимых кодов в реестре должен быть строковым.

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

4.2.7. В рамках проекта подсистема должна обеспечить хранение реестров классификаторов для следующих справочников:

Название справочника	ИС, предоставляющая эталонные справочники	ИС, потребители справочника
Товарно-материальные ценности (ТМЦ)	НСИ	Бухгалтерский учёт, Система бюджетирования
Штатная структура	Система кадрового учёта	Active Directory, СЭД
Персонал	Система кадрового учёта	Active Directory, СЭД
Контрагенты	НСИ	Бухгалтерский учёт, Система бюджетирования

Таб. 2. Справочники в рамках проекта

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

• Слой хранения данных.
  
• Слой Вэб-сервисов для программного доступа к подсистеме.
  
• Слой пользовательского интерфейса в виде тонкого клиента.
  

Схема структуры приведена на рисунке 4.




Рис. 3. Структура подсистемы сопоставления классификаторов


4.2.9. В подсистеме должны быть выделены следующие типы пользователей:

• Системный администратор. Имеет полный доступ к подсистеме и всем реестрам.
  
• Ответственный пользователь. Ответственный пользователь отвечает за ведение определенного реестра классификатора. Он принимает решение по принятию переданных в систему данных или их отклонению или определение соответствий.
  

4.2.10. Подсистема не должна обеспечивать следующие функции:

1. Автоматическое поддержание актуальной информации о соответствии кодов объектов. Актуальность соответствия кодов должна поддерживаться на основании запросов на изменения от внешних ИС через ИШД.
   
2. Первичное наполнение реестра. Первичное наполнение реестра должно производиться отдельным процессом.