Разграничение прав доступа в ЕОСДО · 2020. 5. 22. · На...

Москва 2019

Руководство

администратора

«Электронная система документооборота для

организаций Госкорпорации «Росатом»

I СОДЕРЖАНИЕ

I СОДЕРЖАНИЕ 2

II ТЕРМИНЫ И СОКРАЩЕНИЯ 4

III ВВЕДЕНИЕ 6

1. Общие сведения 6

2. Назначение 6

IV УСЛОВИЯ ПРИМЕНЕНИЯ 8

1. Требования к техническому обеспечению 8

1.1. Описание технического обеспечения 8

1.1.1. Техническое обеспечение 8

1.1.2. Требования к оборудованию рабочих станций 8

1.1.3. Требования к пропускной способности каналов связи 8

1.2. Требования к ПО 8

1.2.1. Требования к системному ПО рабочих станций 8

1.2.2. Требования к ПО серверного оборудования 9

1.3 Требования к квалификации обслуживающего персонала 10

V СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ 11

1. Учетные записи на серверах для установки и администрирования 11

2. Установка и настройка ПО 11

2.1. Окружение для установки ПО 11

2.2. Установка и настройка системного ПО 14

2.3. Установка и настройка прикладного ПО 15

2.4. Установка и настройка клиентского ПО 22

3. Операции по обслуживанию 22

3.1. Мероприятия по текущему обслуживанию комплекса 22

3.2. Регламентные работы 28

3.3. Обновление комплекса 41

3.4. Мониторинг ЕОСДО 44

4. Ошибки работы системы и способы их устранения 45

4.1. Вход в Систему невозможен из-за ввода неправильного имени пользователя 45

4.2. Отображение окна сертификата при работе с Системой 45

4.3. Возможные ошибки при возобновлении работы с Системой после временного

интервала 45

4.4. Возможные ошибки при возврате на предыдущую страницу браузера с

помощью кнопки Back 46

4.5. Возможные ошибки при открытии файлов 46

5. Аварийные ситуации и действия по их устранению 48

5.1. Восстановление работоспособности ЕОСДО 51

3

6. Список Job и их параметры 56

6.1. Системные сервисы (JOB) и расписание их запуска 56

6.2. Параметры системных сервисов (JOB) 60

VI Техническое решение по созданию, установке и настройке отдельной

инсталляции системы ЕОСДО на основе существующего решения 70

1.1 Термины, сокращения и определения 70

1.2 Цель технического решения 71

2 ПРИНЦИПЫ СОЗДАНИЯ ОТДЕЛЬНОЙ ИНСТАЛЛЯЦИИ 71

3 ПЕРЕНОС МОДЕЛИ ДАННЫХ DOCUMENTUM 72

4 ПЕРЕНОС СПРАВОЧНЫХ ОБЪЕКТОВ 73

5 ОПИСАНИЕ УТИЛИТЫ WASABI 74

6 ПЕРЕНОС ЭЛЕМЕНТОВ СТРУКТУРЫ БАЗЫ ДАННЫХ 76

2 7. НАСТРОЙКА РЕПОЗИТОРИЯ DOCUMENTUM 79

8. СОЗДАНИЕ СИСТЕМНЫХ НАСТРОЕК ЕОСДО 79

9. ДОБАВЛЕНИЕ КОНФИГУРАЦИИ ДЛЯ ЛАНДШАФТА СИСТЕМЫ В КОД 79

VII ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ 80

4

II ТЕРМИНЫ И СОКРАЩЕНИЯ

В данном документе использованы следующие термины и сокращения (Таблица 1).

Таблица 1. Термины/сокращения и определения

Термины/Сокращ

ения

Определения

АРМП Автоматизированное рабочее место пользователя

ЕОСДО Единая отраслевая система электронного документооборота

ЖЦ Жизненный цикл

ПО Программное обеспечение

ПП Полнотекстовый поиск

Сервлет Специализированный механизм Java (Java-интерфейс),

используемый для создания WEB ресурсов, реализация которого

расширяет функциональные возможности сервера, и

взаимодействующий с клиентом посредством принципа запрос-

ответ.

СУБД Система управления базами данных

ТП Техническая поддержка

ЦПП Центр поддержки пользователей

ГК «Росатом» Государственная корпорация по атомной энергии «Росатом»

ДЗО Дочерние и зависимые общества

Ландшафт;

Системный

ландшафт

Группа взаимосвязанных систем, объединенных по признаку

функционального предназначения. В рамках данного Проекта

системные ландшафты могут быть представлены следующими

группами: разработка, тестирование, продуктив.

Перенос функциональности между ландшафтами Системы

осуществляется путем переноса релиза.

ОШС Организационно-штатная структура

Проект Проект «Система электронного документооборота для организаций

Госкорпорации «Росатом»»

Репозиторий Место, где хранятся и поддерживаются данные системы

Система ЕОСДО

ТЗ Техническое задание на выполнение работ по проекту «Система

электронного документооборота для организаций Госкорпорации

«Росатом»»

5

ТР Техническое решение по созданию, установке и настройке

отдельной инсталляции системы ЕОСДО на основе существующего

решения

ЦОД Центр обработки данных ГК «Росатом»

ФИО Фамилия, имя и отчество

6

III ВВЕДЕНИЕ

1. Общие сведения

Полное наименование системы:

Единая отраслева система электронного документооборота

Обозначение:

ЕОСДО, Система

2. Назначение

Система электронного документооборота (далее – ЕОСДО) предназначена для

организации процесса распределенного документооборота между организациями ГК «Росатом,

автоматизации процессов и процедур документационного обеспечения управления, обеспечения

защиты и сохранности документов. Функциональность системы реализована в объеме следующих

сценариев:

Cценарий № 01 (Обеспечение распорядительной деятельности)

Cценарий № 02.1 (Обеспечение деятельности коллегиальных органов управления дочерних и

зависимых обществ (ДиЗО))

Cценарий № 02.2 (Обеспечение деятельности коллегиальных органов управления в части

заседаний органов управления)

Cценарий № 03 (Доверенности)

Cценарий № 04 (Договорная работа)

Cценарий № 05 (Внешняя и внутренняя переписка)

Cценарий № 05.1 (Сквозная переписка между предприятиями отрасли)

Cценарий № 06 (Архивная работа)

Cценарий № 08 (Лицензии и сертификаты)

Cценарий № 09 (Судебно-претензионная работа)

Cценарий № 10 (Архив бухгалтерских документов) (Сделки, Captiva)

Cценарий № 12 (Объекты интеллектуальной собственности)

Cценарий № 13 (Взаимодействие ЕОСДО с системой МЭДО)

Cценарий № 14 (Контроль безопасности ЯРОО организаций Госкорпорации Росатом)

Cценарий № 16 (Корпоративная информация)

Cценарий № 17 (Электронный архив документации для учета основных средств)

Cценарий № 18 (Листы исполнения)

7

Cценарий № С1 (Контроль исполнения поручений)

Cценарий № С2 (Общие правила создания и согласования проектов документов)

Cценарий № С3 (Делегирование полномочий и организация прав доступа)

Cценарий № С4 (Управление стандартами, классификаторами и шаблонами, описание

интерфейсов)

Cценарий № С5 (Обработка в ЕОСДО документов, составляющих коммерческую тайну и

служебную тайну)

Cценарий № С6 (Поиск информации и формирование отчетов)

Cценарий № С7 (Интеграция с ЭЦП)

Cценарий № С9 (Рабочее место Генерального директора и его заместителей)

Cценарий интеграционный ЕОСДО с ЕОС - Закупки в части договорной работы

В данном документе описано руководство для технического обслуживания и

администрирования системы.

8

IV УСЛОВИЯ ПРИМЕНЕНИЯ

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

1.1. Описание технического обеспечения

1.1.1. Техническое обеспечение

Описание технического обеспечения системы изложено в документе «Техническое

решение по созданию, установке и настройке отдельной инсталляции системы ЕОСДО на основе

существующего решения».

1.1.2. Требования к оборудованию рабочих станций

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

удовлетворять следующим минимальным требованиям:

процессор с тактовой частотой 1 ГГц;

объем свободной оперативной памяти (ОЗУ) − 1024 МБ;

объем свободного дискового пространства − 4 ГБ;

монитор и видеокарта с поддержкой разрешения 1280х1024 пикселей;

сетевая карта − 100 Мб/с;

клавиатура;

манипулятор «мышь».

1.1.3. Требования к пропускной способности каналов связи

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

менее 1Гб/с

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

долджны быть обеспечены с пропускной способностью не менее 256Кб/с на одного пользователя,

при средней задержке не более 50мс.

1.2. Требования к ПО

1.2.1. Требования к системному ПО рабочих станций

К системному ПО рабочих станций предъявляются следующие требования:

операционная система (ОС) Microsoft Windows 7/8.1/10;

9

обозреватель Internet Explorer 11, обозреватель Chrome версии 56.

1.2.2. Требования к ПО серверного оборудования

Таблица 3. Общие требования к ПО

Роль сервера Используемое системное и прикладное программное обеспечение

Серверы

приложений RedHat Enterprise Linux v.7 Update-5 x86_64;

IBM WebSphere 8.5 (8.5.5.15);

OpenText Documentum Administrator 16.4;

OpenText Webtop 6.8.2.

Серверы Shark

(Метод серверы)

RedHat Enterprise Linux v.7 Update-5 x86_64;

IBM WebSphere 8.5 (8.5.5.15);

ActiveMQ 5.15.8;

Oracle JDK 8.0.212;

MongoDB 4.0

Серверы контента RedHat Enterprise Linux v.7 Update-5 x86_64;

Oracle Database Client 12 (12.1);

OpenText Documentum Content Server 16.4;

Сервер

индексирования RedHat Enterprise Linux v.7 Update-5 x86_64;

OpenText xPlore 16.4;

Сервер СУБД RedHat Enterprise Linux v.7 Update-5 x86_64;

Oracle Database 12 (12.1)

Балансировщики

нагрузки RedHat Enterprise Linux v.7 Update-5 x86_64;

Nginx 1.14;

Nginx-sync;

keepalived

Серверы

хранения данных RedHat Enterprise Linux v.7 Update-5 x86_64;

RedHat Cluster suite;

NFS Server

10

1.3 Требования к квалификации обслуживающего персонала

Для эксплуатации системы предполагается наличие нескольких типов (ролей)

Администраторов Системы:

Системный администратор;

Администратор БД (Oracle DBA);

Администратор сервера приложений IBM WebSphere Application Server;

Администратор OpenText Documentum;

Прикладной администратор.

Один и тот же специалист может совмещать несколько типов (ролей) администраторов.

Системные Администраторы должны обладать следующими навыками:

администрирование ОС Linux – в рамках сертифицированных курсов;

администрирование ОС Windows – в рамках сертифицированных курсов;

администрирование платформы виртуализации VMware – в рамках

сертифицированных курсов;

администрирование системы резервного копирования – в рамках

сертифицированных курсов.

Администраторы БД (Oracle DBA) должны обладать следующими навыками:

администрирование СУБД Oracle 11/12 – в рамках сертифицированных курсов;

диагностика производительности СУБД – в рамках сертифицированных курсов.

Администраторы сервера приложений IBM WebSphere Application Server должны обладать

следующими навыками: администрирование серверов приложений IBM WebSphere Application

Server в кластерной конфигурации – в рамках сертифицированных курсов.

Администраторы OpenText Documentum, прикладные администраторы должны обладать

следующими навыками:

администрирование платформы OpenText Documentum – в рамках

сертифицированных курсов;

администрирование СУБД Oracle 11/12 – в рамках сертифицированных курсов.

11

V СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ

1. Учетные записи на серверах для установки и администрирования

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

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

сервереа очередей

oracle – учетная запись, владелец установки сервера СУБД

dmadmin – учетная запись, владелец установки контент-серверов

2. Установка и настройка ПО

2.1. Окружение для установки ПО

Для установки базового программного обеспечения необходим обеспечить наличие

следующих библиотек и пакетов:

Для сервера СУБД:

inutils-2.23.52.0.1-12.el7.x86_64

compat-libcap1-1.10-3.el7.x86_64

compat-libstdc++-33-3.2.3-71.el7.i686

compat-libstdc++-33-3.2.3-71.el7.x86_64

gcc-4.8.2-3.el7.x86_64

gcc-c++-4.8.2-3.el7.x86_64

glibc-2.17-36.el7.i686

glibc-2.17-36.el7.x86_64

glibc-devel-2.17-36.el7.i686

glibc-devel-2.17-36.el7.x86_64

ksh

libaio-0.3.109-9.el7.i686

libaio-0.3.109-9.el7.x86_64

libaio-devel-0.3.109-9.el7.i686

libaio-devel-0.3.109-9.el7.x86_64

libgcc-4.8.2-3.el7.i686

libgcc-4.8.2-3.el7.x86_64

12

libstdc++-4.8.2-3.el7.i686

libstdc++-4.8.2-3.el7.x86_64

libstdc++-devel-4.8.2-3.el7.i686

libstdc++-devel-4.8.2-3.el7.x86_64

libXi-1.7.2-1.el7.i686

libXi-1.7.2-1.el7.x86_64

libXtst-1.2.2-1.el7.i686

libXtst-1.2.2-1.el7.x86_64

make-3.82-19.el7.x86_64

sysstat-10.1.5-1.el7.x86_64

Для контент-сервера:

xorg-x11-font-utils.x86_64

xorg-x11-fonts-100dpi.noarch

xorg-x11-fonts-75dpi.noarch

xorg-x11-fonts-Type1.noarch

xorg-x11-xauth.x86_64

libX11.x86_64

dbus-x11.x86_64

xorg-x11-server-utils.x86_64

xorg-x11-xkb-utils.x86_64

xterm xorg-x11-xauth

xorg-x11-utils

xorg-x11-fonts-*

xorg-x11-apps

xorg-x11-server-Xorg

libXp gcc make setarch

libaio glibc-devel glibc.i686

libXp.so.6 libXt.so.6

libXtst.so.6

compat-libstdc++-33.x86_64

binutils elfutils-libelf

elfutils-libelf-devel

glibc

glibc-common

13

glibc-devel

glibc-headers

gcc

gcc-c++

libaio-devel

libaio

libgcc

libstdc++

make

sysstat

unixODBC

unixODBC-devel

unzip

glibc-devel.i686

libgcc.i686

binutils

compat-db

libstdc++

gdbm

make

ksh

libaio-devel

libXtst

xorg-x11-utils

openmotif

openmotif.i686

libaio.i686 l

ibaio-devel.i686

compat-glibc.x86_64

compat-libcap1

dejavu-fonts-common.noarch

dejavu-sans-fonts.noarch

Для сервера приложений:

gtk2

14

libXtst

xorg-x11-fonts-Type1

psmisc

2.2. Установка и настройка системного ПО

Перед установкой ПО системы необходимо выполнить установку и настройку системного

ПО в соответствии с документацией производителей.

2.2.1. Предварительные требования

2.2.1.1. Сервер СУБД

На сервере СУБД должно быть установлено ПО Oracle Database Server 12c (12.1) и создан

экземпляр базы данных в режиме DEDICATED со следующими параметрами:

NLS_CHARACTERSET = AL32UTF8;

open_cursors = 600; (мимнимальное рекомендованное значение)

cursor_sharing = FORCE;

Рекомендуется увеличить размер каждого журнального файла Redo Log до 512 MБ.

2.2.1.2. Резервный сервер СУБД

На резервный сервер СУБД должно быть установлено ПО Oracle Database Server 12c

(12.1).

Настройка сервера горячего резервирования осуществляется согласно инструкции Oracle

Database 12c Release 1 Data Guard Concepts and Administration

2.2.1.3. Сервер контента

На сервере контента необходимо установить ПО Oracle Database Client 12.1и OpenText

Documentum Content Server 16.4 согласно инструкции OpenText Documentum Content Server

Installation Guide (Version 16.4). В репозитории настроены подключения к нужным серверам

LDAP, необходимым для осуществления аутентификации средствами Microsoft Active Directory

(см. OpenText Documentum Content Server Administration Guide).

2.2.1.4. Сервер приложений и метод сервер.

На сервере приложений должно быть установлено ПО IBM WebSphere 8.5.5.15.

Необходимо создать отдельные экземпляры сервера для каждой из нод. Развернут инстанс

ActiveMQ. Для работы сервисов федерации должна быть развернута MongoDB 4.0.

2.2.1.5. Сервер индексирования

Должно быть установлено ПО OpenText xPlore 1.6 согласно инструкции OpenText

Documentum Content Server Fulltext Indexing System Installation and Administration Guide, должен

быть создан агент индексирования, настроенный для работы с репозиторием на сервере контента.

15

2.2.1.6. Сервер балансировки нагрузки

Должно быть установлено ПО Nginx 1.14 с модулем nginx-sticky-module.

2.3. Установка и настройка прикладного ПО

2.3.1. Предварительные требования

Необходимо установить и настроить базовое системное ПО согласно документации,

предоставляемой поставщиком системного ПО (ОС, требуемые версии пакетов и т.д.).

2.3.2. Системные конфигурационные файлы

Конфигурационные файлы системы автоматически пакуются при сборке внутрь war-

приложений, дополнительное конфигурирование не требуется. Способ сборки приложения

исключает необходимость дополнительной ручной настройки.

Конфигурационные файлы прикладного ПО, уникальные для каждой из площадок,

расположены на серверах, указанных в Таблице 4.

Таблица 4. Конфигурационные файлы прикладного ПО.

Сервер Путь Параметры

Контент

серверы

/dm/имя_репозитор

ия/dba/config/rosato

m_mb/server.ini

[SERVER_STARTUP]

docbase_id =ID репозитория (уникален для

каждого репозитория)

docbase_name = имя репозитория

server_config_name = имя конфигурации

репозитория

database_conn = подключение к СУБД

database_owner = имя владельца репозитория

database_password_file = путь к

зашифрованному паролю СУБД

service = имя сервиса репозитория в ОС

[DOCBROKER_PROJECTION_TARGET] –

параметры проецирования репозитория на

докброкеры плошадки

Подробнее в OpenText Documentum Content

Server Version 16.4 Administration and

Configuration Guide

dm/oracle/product/12

.1.0/client_1/network

/admin/tnsnames.ora

Параметры подключения репозитория к

СУБД

16


/dm/имя_репозитор

ия/shared/config/dfc.

properties

Конфигурация DFC сервисов

dfc.data.dir= каталог с данными dfc, создается

автоматически при наличии прав при установке или

может быть указан вручную

dfc.tokenstorage.dir= путь к ключу безопасности dfc

клиента, создается при обращении клиента к

репозиторию, при установке или может быть указан

вручную

dfc.tokenstorage.enable=false

dfc.docbroker.host[0]= адрес хоста, на котором

развернуто ПО Documentum, где работает докброкер


dfc.docbroker.port[0]= порт докброкера репозитория

dfc.docbroker.host[1]=адрес хоста, на котором

развернуто ПО Documentum, где работает докброкер

репозитория, используется при наличии

многосерверной конфигурации

dfc.docbroker.port[1]=порт докброкера репозитория,

используется при наличии многосерверной

конфигурации

dfc.crypto.repository= наименовение репозитория,

который осуществляет криптозащиту dfc клиентов

dfc.session.secure_connect_default= параметры

подключения, используется умолчание

dfc.globalregistry.repository= наименование

репозитория, являющегося global registry

dfc.globalregistry.pass = зашифрованный пароль

пользователя global registry

Подробнее в Documentum Foundation Classes 16.4

Development Guide и OpenText Documentum Content

Server Version 16.4 Administration and Configuration

Guide

17


Серверы

полнотекстового

поиска

/fti/xPlore/config/ind

exserverconfig.xml

/fti/xPlore/dsearch/

Конфигурация сервисов полнотекстового

поиска, подробнее см. в OpenText ™

Documentum® xPlore Version 16.4

Administration and Development Guide

Серверы Shark /etc/mongod.conf Параметры конфигурации сервисов

федеративного обмена

/opt/app/activemq/co

nf

Серверы

балансировки

нагрузки

/usr/local/nginx/ngin

x.conf

Конфигурация балансировки нагрузки Nginx

Описание сборок и основных конфигурационных файлов

Для упаковки правильных конфигурационных файлов в артефакты приложений системы

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

профиль:

devmb – для стенда разработки

testmb – для стенда тестирования

prodmb – для продуктивного стенда.

Для каждого профиля в коде системы хранится набор конфигурационных файлов, которые

пакуются в артефакты приложений Системы. Пароли от учетных записей не хранятся в системе

контроля версий и передаются maven как параметры сборки (через -D):

env.eosdo.jdbc.password – пароль пользователя базы данных

env.dfc.globalregistry.password – пароль пользователя общего реестра репозитория

env.SUPERUSER_PASSWORD – пароль администратора основного репозитория

env.RepositoryOwnerPassword – пароль администратора основного репозитория

env.archiveRepositoryPassword – пароль администратора архивного репозитория

Основные конфигурационные файлы, содержащие информацию о Системе:

Имя

файла

Расположение в war-

файле Свойство Описание

dfc.properties \WEB-

INF\classes\dfc.properties

dfc.docbroker.host Ip доброкера

репозиториев

18

Имя

файла



dfc.docbroker.port Порт

докброкера

репозиториев

dfc.globalregistry.repository Имя

основного


dfc.globalregistry.username Имя

пользователя

общего

реестра


dfc.globalregistry.password Пароль


общего

реестра


common.pr

operties

\WEB-

INF\classes\common.properties

SUPERUSER_PASSWOR

D

пароль

администрато

ра основного


SUPERUSER_LOGIN имя




Repository.

properties

\WEB-

INF\classes\ksed\Repository.

properties,

\WEB-

INF\classes\eosdo\Repository

.properties

\WEB-

INF\classes\archive\Reposito

ry.properties

repositoryOwnerUserName пароль




repositoryOwnerPassword имя




archiveRepositoryPassword пароль


ра архивного


19

Имя

файла



repositoryName Имя

основного


archiveRepositoryName Имя

архивного


2.3.3. Логирование, описание и настройка

2.3.3.1. Основные понятия

2.3.3.1.1. Понятие аппендера (Appender)

Аппендер – класс, часть подсистемы логирования, отвечающая за вывод лога во

внешнюю систему (например, файл, БД).

В ЕОСДО используется подход, при котором логи выгружаются в файл и аппендеры в

данной конфигурации отвечают за:

организацию в файловой системе (ежедневное архивирование как заданное

ограничение на содержание данных в одном файле);

кодировку;

форматирование сообщений;

фильтрацию входящих сообщений по уровню.

2.3.3.1.2. Понятие логгера (Logger)

Логгер – подсистема заполнения журналов событий (логирование), которая принимает

сообщения из системы и перенаправляет их соответствующим аппендерам.

2.3.3.1.3. Уровни логирования

Ниже приведен перечень уровней логирования, отсортированных по важности в порядке ее

возрастания:

TRACE;

DEBUG;

INFO;

WARN;

ERROR;

FATAL.

20

2.3.3.1.4. Файлы логов (аппендеры ЕОСДО)

Уровень лога файла указывает на уровень важности логов, попадающих в файл. Ниже

приведен перечень названий файлов и масок названий файлов, в которых хранятся логи

соответствующего уровня важности:

1) log4j.log – корневой файл с логами, принимает сообщения со всех логгеров.

Уровень логов, находящихся в файле – WARN.

2) trace.log – файл, в котором хранятся логи с уровнем TRACE и выше.

3) debug.log – файл, в котором хранятся логи с уровнем DEBUG и выше.

4) info.log – файл, в котором хранятся логи с уровнем INFO и выше.

5) warn.log – файл, в котором хранятся логи с уровнем WARN и выше.

6) *.log – файл с логами, специфичными для какого-либо функционального модуля.

Уровень логов обычно достаточно низкий (ALL | TRACE | DEBUG).

7) *.<Дата> - сохраненный файл с логами за указанную дату.

2.3.3.1.5. Логгеры системы

1) Любые логи, порождаемые классами системы, направляются в базовые аппендеры

(trace.log, debug.log, info.log, warn.log). Уровень логов, как правило, ограничивается INFO.

8) Любые логи, порождаемые классами системы и всех сопутствующих библиотек

(Documentum, Aspose и т.д), направляются в аппендер по умолчанию log4j.xml.

Уровень логов обычно ограничивается WARN. Таким образом, инженер поддержки

системы может в короткое время ознакомиться со всеми возможными проблемами в

работе системы в целом.

9) Любые логгеры, специфичные для какой-либо подсистемы, например, подсистемы

запросов DQL, подсистемы работы с сессией.

2.3.3.2. Дополнительные сведения

При старте сервера необходимо указать директорию для хранения логов, для этого

требуется задать значение системного свойства log_path. Значение свойства задается при старте

контейнера ключом –D.

Например,

set JAVA_OPTS=-Xmx1000m –Xdebug –

Xrunjdwp:transport=dt_socket,address=8010,server=y,suspend=n –Dlog_path=»D:/logs»

где =»D:/logs» каталог, в который будут писаться логи системы.

Настройки логирования приложения описаны в конфигурационном файле WEB-

INF/classes/log4j.xml (находится внутри war-файла приложения Системы).

Дополнительно создаются следующие файлы (раздел Component specific appenders файла

log4j.xml):

new_update_component.log (логирование Администрирование «Список

обновлений»);

new_clientfx.log (логирование взаимодействия с client fx);

new_capability-service.log (логирование службы доступности элементов

21

управления, связанных со свойствами модели);

new_work-delegation.log (логирование действий, выполняемых при

увольнении/освобождении/переназначении сотрудника);

new_dict-access.log (логирование компоненты обновления прав доступа к

справочникам);

new_user-login.log (логирование сервиса аутентификации пользователей);

new_reports.log (логирование сервиса работы с отчетами);

new_registration.log (логирование сервиса формирования регистрационного

номера);

outgoing_signer.log (логирование текущего подписанта исходящего документа

при сохранении документа на стадии Согласование);

new_formlogger.log (логирование старта и окончания рендеринга, запускаемых

веб-форм приложения);

deprecated_usage.log (логирование использования устаревших кодовых

конструкций);

archive_year_creation.log (логирование компоненты создания папок по годам в

оперативном архиве Системы);

Так же могут присутствовать пустые файлы журналов, функциональности

ЕОСДО:

new_erp-integration.log;

new_sap-integration-external.log;

new_sap-integration-parse.log;

new_sap-integration-server.log;

new_sap-integration-axis.log;

new_contract.log;

new_contract-lifecycle.log;

new_contract-container.log;

new_rid_request.log;

new_rid_response.log;

new_rid_update.log;

new_rid_update_states.log.

2.3.4. Установка системы

Порядок создания, установки и настройки системы описан в Техническом решении по

созданию, установке и настройке отдельной инсталляции системы ЕОСДО на основе

существующего решения.

22

2.4. Установка и настройка клиентского ПО

2.4.1. Настройка web-браузера Google Chrome

Руководство по настройке браузера приводится в документе «ИНСТРУКЦИЯ ПО

НАСТРОЙКЕ РАБОЧЕГО МЕСТА ПОЛЬЗОВАТЕЛЯ».

3. Операции по обслуживанию

3.1. Мероприятия по текущему обслуживанию комплекса

3.1.1. Учетные записи для администрирования

Для выполнения работ по администрированию необходимо использовать специальные

учетные записи.

1) Сервер СУБД и резервный сервер СУБД (standby):

а) oracle – владелец инсталляции ПО ORACLE Database;

б) sys – системный пользователь СУБД;

в) system – системный пользователь СУБД;

г) rosatom – пользователь СУБД, владелец схемы репозитория rosatom.

2) Сервер контента:

а) dmadmin – владелец инсталляции, суперпользователь Documentum.

3) Сервер приложений:

а) ibm - владелец инсталляции ПО IBM WebSphere Application Server;

б) wasadmin – системный пользователь WAAS для подключения к консоли

управления WebSphere Application Server (WebSphere Integrated Solutions

Console).

4) Сервер Shark (метод сервер):

а) ibm - владелец инсталляции ПО IBM WebSphere Application Server;

б) wasadmin – системный пользователь WAAS для подключения к консоли

управления WebSphere Application Server (WebSphere Integrated Solutions Console).

5) Сервер индексирования:

а) dmadmin - владелец инсталляции, суперпользователь Documentum.

6) Балансировщики нагрузки:

а) nginx – пользователь ОС, с правами которого работают процессы сервера

балансировки нагрузки (NGINX);

23

3.1.2. Смена паролей системных пользователей

Таблица 5. Процедура смена паролей для системных учетных записей.

Учетная запись Смена пароля

dmadmin, владелец

установки ПО

ibm, владелец

установки ПО

Осуществляется штатными способами ОС

passwd

Остановка системы не требуется.

dmadmin,

суперпользователь


Через интерфейс Documentum Administrator в ветке дерева

администрирования users, пароль должен быть типа inline password

При смене пароля dmadmin требуется обновить пароль в настройках


Требуется рестарт системы для применения конфигурации с новым

паролем

Требуется сборка и обновление системы

24

Учетная запись Смена пароля

Владелец схемы

репозитория в

СУБД

Смена пароля на продуктивной среде не рекомендуется!

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

Остановить все сервисы репозитория

Выставить переменную окружения: export

R_SHLIB_LD_LIBRARY_PATH=$DOCUMENTUM/product/16.4/bin

/FIPS

Перейти на первом контент сервере в директорию

$DM_HOME/dba/config/ROSATOM_MB или

$DM_HOME/dba/config/ROSATOM_MB_ARCH

Сделать копию файла dbpasswd.txt

Сменить пароль для пользователя ROSATOM_MB или

ROSATOM_MB_ARCH в СУБД

Внести изменения в файл dbpasswd.txt, заменить зашифрованный

пароль новым паролем в формате plain text (не зашифрованный)

Сохранить dbpasswd.txt

Перейти в директорию: $DM_HOME/bin и выполнить:

dm_encrypt_password –location /opt/documentum/dba/secure/CSaek -

docbase <docbase name> -rdbms -encrypt <database password>

Скопировать файл dbpasswd.txt на второй контент сервер (при

наличии).

Стартовать сервисы репозитория

3.1.3. Порядок остановки системы

Остановку системы необходимо выполнять в следующей последовательности:

1) Сервера балансировки нагрузки

Из под пользователя root остановить сервер nginx

# systemctl stop nginx.service

2) Сервер приложений (Выполнить на каждой ноде из пула серверов приложения).

Из под пользователя владельца установки (ibm):

cd $WS_PROFILEDIR/bin

Команда: ./stopServer.sh <AS_NAME>

Где <AS_NAME> имя сервера приложений (например, ic-s-sedapp01)

25

Из под пользователя root остановить промежуточный сервер nginx

# systemctl stop nginx.service

Из под пользователя root остановить менеджер нод

# /etc/init.d/node_manger_name_was.init stop

3) Метод сервер

Из под пользователя владельца установки:


Команда: ./stopServer.sh <AS_NAME>


Из под пользователя root остановить менеджер нод

# /etc/init.d/node_manger_name_was.init stop

4) Сервер индексирования.

Остановка сервисов:~/bin/stop_all_rosatom.sh от пользователя dmadmin

5) Сервер контента репозитория rosatom.

Последовательно остановить сервер методов Java, сервисы репозитория rosatom и

процесс докброкер, выполнив команды, соответственно:

$DOCUMENTUM_SHARED/$JMS_VERSION/server/stopMethodServer.sh

dm_shutdown_rosatom

dm_stop_Docbroker

6) Сервер контента репозитория rosatom_arch.

Последовательно остановить сервер методов Java, сервисы репозитория rosatom и

процесс докброкер, выполнив команды, соответственно:

$DOCUMENTUM_SHARED/$JMS_VERSION/server/stopMethodServer.sh

dm_shutdown_rosatom_arch

dm_stop_Docbroker

7) Резервный сервер СУБД (standby).

Для остановки резервного сервера БД выполнить команду:

sqlplus / as sysdba

SQL> alter database recover managed standby database cancel;

Для остановки процесса Oracle Listener выполнить команду:

lsnrctl stop

8) Сервер СУБД.

Для остановки экземпляра БД выполнить команду:

sqlplus / as sysdba

SQL> shutdown immediate

26

Для остановки процесса Oracle Listener выполнить команду:

lsnrctl stop

3.1.4. Порядок запуска системы

Запуск системы выполняется в обратном порядке:

1) Сервер СУБД.

Для запуска процесса Listener выполнить:

lsnrctl start

Для запуска экземпляра БД выполнить:

sqlplus / as sysdba

SQL> startup

2) Резервный сервер СУБД (standby)

Для запуска процесса Listener выполнить:

lsnrctl start

sqlplus / as sysdba

SQL> alter database recover managed standby database using current logfile disconnect from

session;

3) Сервер контента репозитория rosatom_arch.

Последовательно выполнить команды:

dm_launch_Docbroker

dm_start_rosatom_arch

$DOCUMENTUM_SHARED/$JMS_VERSION/server/startMethodServer.sh

4) Сервер контента репозитория rosatom.

Последовательно выполнить команды:

dm_launch_Docbroker

dm_start_rosatom

$DOCUMENTUM_SHARED/$JMS_VERSION/server/startMethodServer.sh

5) Сервер индексирования.

Старт сервисов:~/bin/stop_all_rosatom.sh от пользователя dmadmin. Скрипт выполняет

запуск процессов dsearch и IndexAgent, а также выполняет команду API для запуска Агента

Индексирования в репозитории.

6) Сервер приложений (Выполнить на каждой ноде из пула серверов приложения).

Из под пользователя root запустить менеджер нод

# /etc/init.d/node_manger_name_was.init start

Из под пользователя root запустить промежуточный сервер nginx

27

# systemctl start nginx.service



Команда: ./startServer.sh <AS_NAME>


7) Метод сервер

Из под пользователя root запустить менеджер нод

# /etc/init.d/node_manger_name_was.init start



Команда: ./startServer.sh <AS_NAME>


8) Сервера балансировки нагрузки

Из под пользователя root выполнить

# systemctl start nginx.service

3.2. Регламентные работы

Таблица 6. Перечень регламентных работ

Краткое описание Подробное описание Время проведения

[Регламентная работа]

Мониторинг серверов.

1. Провести мониторинг нагрузки CPU APP/CS/DB

2. Провести мониторинг сессий APP

3. Проверить доступность ЕОСДО по https

4. Проверить доступность серверов приложений по http

5. Проверить сообщения систем мониторинга на наличие ошибок

6. Проверить логи APP/CS на наличие error, fatal ошибок.

7. Проверить свободное пространство на файловых системах продуктивных серверов

(APP/CS/INDEX/DB/SHARK)

В начале и конце

рабочего дня


Сценарий 5.1. Проверить наличие необработанных документов 5.1 В начале каждого дня,

проверка за

предыдущий день


Мониторинг состояния.

1. Утилизации CPU APP/CS/DB/SHARK

2. Количества сессий APP/CS

3. Сообщений систем мониторинга

В течение рабочего

дня


Мониторинг

приложения.

1. Проверить наличие ошибок в логе

2. Проверить доступность приложений системы через браузер

3. При возникновении ошибки – проверить, влияет ли ошибка на функционирование

приложения, если не влияет – собрать логи и дамп процесса приложения, если влияет –

перезапустить экземпляр сервера приложений

4. Проверить отсутствие ошибок в логе

При возникновении

инцидента

3.2.1. Обслуживание прикладной части системы.

Система базируется на программном комплексе OpenText Documentum 16.4 и

представляет собой набор сервисов данной платформы, включающий:

a) Сервисы брокера соединений,

b) Сервисы репозитория,

c) Сервисы Java Method сервера,

Дополнительные компоненты платформы.

3.2.1.1. Описание компонентов системы ПП.

Прикладной комплекс OpenText Documentum развернут в /dm/, владельцем установки

является пользователь dmadmin. Экземпляры сервисов представлены следующими компонентами:

a) /dm/cs-rosatom_mb – домашний каталог системной части приложений репозитория системы,

b) /dm/cs-rosatom_mb_arch – домашний каталог системной части приложений репозитория

Архива,

c) /dm/cs-rosatom_mb/shared/wildfly11.0.0 – экземпляр Java Method Server для репозитория

системы,

d) /dm/cs-rosatom_mb_arch/shared/wildfly11.0.0 – экземпляр Java Method Server для репозитория

Архива,

e) /dm/data/rosatom* - каталоги СХД репозиториев.

3.2.1.2. Методика сопровождения прикладной части системы.

Управление системой осуществляется в соответствии с документацией вендора: OpenText

™ Documentum® Server Version 16.4 Administration and Configuration Guide, в которой описана

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

сопровождения платформы.

Основной мониторинг и обслуживание системы производится из командной строки хоста

с помощью CLI интерфейса idql или iapi и интерфейса управления – Documentum Administrator,

обращение к которому осуществляется через веб браузер по адресу: http://appserver_hostname/da.

http://appserver_hostname/da

30

В командной строке операции, выполняемые через интерфейс idql и iapi, осуществляются

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

. ~/.docu_env_ROSATOM – переменные для репозитория rosatom_mb,

. ~/.docu_env_ROSATOM_ARCH – переменные для репозитория rosatom_mb_arch.

В качестве вспомогательного механизма для администрирования репозиториев, после

загрузки соответствующих переменных, доступно использование скрипта

run_script_ROSATOM.sh и run_script_ROSATOM_ARCH.sh, соответственно. Данные скрипты

упрощают выполнение sql, dql и api скриптов.

3.2.1.3. Остановка и старт сервисов репозиториев.

Остановка сервисов:

stop_all_ROSATOM.sh

stop_all_ROSATOM_ARCH.sh

Старт сервисов:

start_all_ROSATOM.sh

start_all_ROSATOM_ARCH.sh

3.2.1.4. Мониторинг и контроль сервисов.

Платформа OpenText Documentum включает набор скриптов для мониторинга активности

процессов и доступности репозитория и сервисов для пользователей и клиентских приложений.

Эти скрипты включены в установку контент сервера, они могут быть задействованы любым

программным комплексом мониторинга или администратором в консоли хоста контент сервера.

31

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

OPENTEXT Documentum Content Server. Результатом выполнения скриптов является возврат

значения в переменной $?.

0 – в случае доступности процесса

любое иное значение – в случае отказа/недоступности процесса

Таблица 7. Средства мониторинга статуса сервисов OpenText Documentum

Сервис Скрипт Местонахож

дение Синтаксис

Content

Server

ContentSer

verStatus

Java

программа в

файле server-

impl.jar

Синтаксис команды:

java

com.documentum.server.impl.utils.ContentServerStatus -

docbase_name «repository_name» -user_name

«user_name»

repository_name – имя репозитория для проверки

доступности.

user_name – учетная запись, используемая для

соединения с репозиторием

Результат работы команды будет отражен в

переменной $?.

Connectio

n

broker

dmqdocbro

ker

Расположен в

$DM_HOME/

bin


$DM_HOME/bin/dmqdocbroker -t

host_name -c ping

host_name - имя машины с процессом докброкера.



Java

method

server

TestConne

ction

Java

программа в

файле server-

impl.jar


java TestConnection host port servlet

host – имя машины с Java Method Server (JVM).

port – порт, используемый JVM



Индекс-

агент

IndexAgent

Ctrl


java com.documentum.server.impl.utils.IndexAgentCtrl

-docbasename repositoryname -username username -

32

Сервис Скрипт Местонахож

дение Синтаксис

action status

repository_name – имя репозитория для проверки

доступности.

user_name – учетная запись, используемая для

соединения с репозиторием



3.2.1.5. Мониторинг производительности.

На хостах КТС ЕОСДО установлен пакет sysstat, входящий в дистрибутив RHEL. С

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

Таблица 8. Средства сбора метрики производительности sar.

Команда Описание

sar -b 3 10 Мониторинг дисковой i\o активности

sar -r 3 10 Статистика памяти и использования swap

sar -n DEV 3 10 Статистика сети

sar -P ALL 3 10 Статистика использования CPU

LC_ALL=C sar -A > /tmp/sar.data.txt Сбор статистики в файл для анализа ksar

Суточные графики-отчеты хранятся в sar файлах по адресу /var/log/sa.

3.2.1.6. Выполнение служебных работ.

Платформа OpenText Documentum включает набор утилит для администрирования и

оптимизации производительности. Эти утилиты включены в установку контент сервера, и

запускаются автоматически по расписанию, с помощью преднастроенных системных работ.

Месторасположение: Documentum Administrator >> Имя_репозитория >> Administration >> Job

Managemtnt >> Jobs.

Таблица 9. Перечень системных работ репозитория OpenText Documentum.

Список системных работ OpenText Documentum

Работа Функционал работы

Рекомендуемая

регулярность

выполнения

работы

33

dm_ConsistencyChe

cker

Автоматическое выполнение утилиты

администратора Consistency Checker

Детальное описание утилиты приведено в

разделе 3.2.1.6.2

При необходимости

dm_ContentWarnin

g


администратора Content Warning, которая

осуществляет мониторинг свободного места для

областей хранения контента

Ежедневно, по

окончании рабочего

дня

dm_DBWarning


администратора Database Space Warning,

которая осуществляет мониторинг свободного

места и наличия фрагментации для таблиц и

индексов базы данных

Ежедневно, по

окончании рабочего

дня

dm_DMClean


администратора Dmclean, которая

осуществляет сканирование репозитория с

целью поиска устаревших (orphaned) объектов и

создает скрипт для возможности их удаления

dm_DMFilescan


администратора Dmfilescan, которая

осуществляет сканирование областей хранения

контента с целью поиска файлов без

метаданных и создает скрипт для возможности

их удаления

dm_QueueMgt


администратора Queue Management, которая

осуществляет удаление неиспользуемых

(dequeued) объектов dmi_queue_item

dm_AuditMgt


администратора Audit Management, которая

осуществляет удаление неиспользуемых

(unneeded) объектов dm_audittrail

34

dm_UpdateStats


администратора Update Statistics для

оптимизации работы базы данных с запросами

dm_LogPurge


администратора Log Purge для удаления

устаревших логов и файлов отчетов

dm_DataDictionary

Publisher


администратора Data Dictionary Publisher,

которая осуществляет обновление

(публикацию) информации о типах объектов и

атрибутах


dm_StateOfDocbase


администратора State of the Repository Report

для получения актуальной сводной информации

о репозитории


Связанные документы/ссылки:

OpenText Documentum Content Server Version 16.4 Administration and Configuration Guide

(Chapter 11, Logging and Tracing)

3.2.1.6.1. Мониторинг работы (анализ системных журналов контент сервера).

Сбор информации в системных логах сервера контента для выявления потенциальных

проблем в работе.

Анализ системных журналов:

a) контент сервера: $Documentum\dba\log\имя_репозитория.log

b) метод сервера: $Documentum\shared\jboss11.0.0\server\DctmServer_MethodServer\logs\




35

3.2.1.6.2. Проверка целостности (согласованности) репозитория.

Для проверки целостности репозитория используется встроенная в OpenText Documentum

Content Server утилита администратора Consistency Checker, которая сканирует репозиторий и

сообщает любые несогласованности, такие как:

повреждение типов и объектов,

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

Механизм Consistency Checker не пытается исправлять эти несогласованности.

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

ошибок, которые могу быть выявлены Consistency Checker, приведены в OpenText Documentum

Content Server Administrator’s Guide (Appendix A, Consistency Checks).

Выполнение системной работы dm_ConsistencyChecker создает отчет с перечнем

исследованных категорий и выявленных несогласованностей. Отчет записывается в репозиторий

по адресу: /System/Sysadmin/Reports/ConsistencyChecker.

Если в результате проверки целостности ошибки выявлены не были, новый отчет

записывается поверх прежнего, если ошибки выявлены – отчет сохраняется, как новая версия

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

запускается 1 раз в день, но возможно запускать утилиту администрирования Consistency Checker,

по необходимости, вручную, используя для этого следующую командную строку:

dmbasic -fconsistency_checker.ebs -eEntry_Point --repository_name superuser password

repository_name – репозиторий, в отношении которого инициирован процесс.

superuser – учетная запись суперпользователя репозитория.

password – пароль суперпользователя репозитория




3.2.2. Обслуживание системы полнотекстового поиска xPlore.

Сервер полнотекстового поиска представляет собой совокупность развернутого ПО

OpenText xPlore 16.4, состоящую из экземпляров приложений dsearch, indexagent и

дополнительных инструментов для конфигурации, сопровождения и восстановления

функционала полнотекстового поиска (далее - ПП).

36

3.2.2.1. Описание компонентов системы ПП.

Прикладной комплекс xPlore развернут в /dm/xPlore/, владельцем установки является

пользователь dmadmin. Экземпляры сервера ПП представлены следующими компонентами:

f) /dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/ - основной сервер ПП,

g) /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/ - индекс-агент для рабочего

репозитория системы,

h) /dm/xPlore/data/ - область хранения системных данных и данных коллекции default сервера

индексации,

i) /dm/xPlore/dsearch/admin/ - область хранения инструментария администрирования сервера

ПП через CLI (интерфейс командной строки),

j) /dm/xPlore/dsearch/xhive/admin/ - область хранения инструментария администрирования

базы данных xhive ПП через CLI (интерфейс командной строки),

k) /dm/xPlore/setup/indexagent/tools/ - область хранения инструментария для управления

консистенцией и соответствием индекса ПП данным репозитория.

3.2.2.2. Методика сопровождения системы ПП.

Управление системой ПП осуществляется в соответствии с документацией вендора:

OpenText ™ Documentum® xPlore Version 16.4 Administration and Development Guide, в которой

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

оптимизации и конфигурации служб ПП.

Основной мониторинг и обслуживание системы ПП производится из командной строки

хоста ПП и интерфейса управления ПП – dsearchadmin, обращение к которому осуществляется

через веб браузер по адресу: http://url.

37

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

бинарнными файлами:

a) /dm/xPlore/dsearch/admin/xplore.sh – выполнение операций по мониторингу, сбору

статистики, резервному копированию и восстановлению,

b) /dm/xPlore/dsearch/xhive/admin/XHAdmin – выполнение операций по обслуживанию,

резервному копированию федерации ПП, восстановлению, проверки консистентности базы

данных ПП (имеет графический интерфейс),

c) /dm/xPlore/dsearch/xhive/admin/XHCommand – выполнение операций по обслуживанию

базы данных xhive ПП,

d) /dm/xPlore/setup/indexagent/tools/ftintegrity_for_****.sh – инструментарий управления

коллекцией индексов ПП.

Подробные сведения о предназначении, выполнении рутинных задач, синтаксисе,

приводятся в документации вендора, указанной в начале раздела.

3.2.2.3. Описание базовых задач по обслуживанию системы ПП.

Проверка состояния сервисов осуществляется несколькими способами:

a) Доступность сервера индексации – http://url.9300/dsearch - отображается версия и статус

dsearch,

b) Доступность индекс-агента – http://url:9200/IndexAgent - отображается страница

авторизации индекс-агента, далее, после аутентификации – статус агента и интерфейс

управления параметрами работы и конфигурации индекс-агента,

c) Состояние сервисов сервера ПП через панель управления xPlore Administrator – в разделе

System Overview,

d) Статус сервисов, журналы, статистика – отображаются в разделе панели управления xPlore

Administrator – Instances, или в журналах на фс:

/dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/logs/,

http://url:9200/IndexAgent

38

e) /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/logs/.

f) Журналы экземпляров сервисов находятся в /dm/xPlore/logs/.

g) Состояние очереди dmi_queue_items для сервера полнотекстовой индексации отображается

в результате выполнения запросов dql в интерфейсе Documentum Administrator.

3.2.2.4. Остановка и старт сервисов ПП.

Остановка сервисов: ~/bin/stop_all_rosatom.sh

Скрипт включает: запуск сервера dsearch, запуск сервиса IndexAgent и выполнение

команды API для запуска Агента Индексирования в репозитории

Старт сервисов: ~/bin/start_all_rosatom.sh

Скрипт выполняет остановку сервисов dsearch и IndexAgent, а также остановку всех

связанных java процессов.

Контроль старта сервисов:

ll /dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/deployments/

ll /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/deployments/

Все приложения должны быть в статусе deployed.

ps -ef | grep JAVA_LINK – должно быть в активном состоянии два процесса java, по одному для

каждого из экземпляров сервисов ПП.

39

3.2.2.5. Запросы для мониторинга очереди индексации в репозитории.

Смотрим, какие события регистрируются в очередь

select * from dmi_registry where is_audittrail=0 and user_name like 'dm_fulltext_index_user%'

Количество dmi_queue_item, используемое очередью индексации

select name,count(name) from dmi_queue_item where name like 'dm_fulltext_index_user%'

group by name

Смотрим, какие типы индексируются

select name from dm_type where r_object_id in (select distinct registered_id from dmi_registry

where user_name='dm_fulltext_index_user')

3.2.2.6. Сбор статистики работы системы ПП.

Сбор статистики о работе сервера полнотекстового поиска запускается через панель

управления xPlore: Diagnostic and Utilities – Reports.

Рекомендуемые отчеты: User Activity Report, Query Counts By User, Indexing Metrics.

Данные отчеты рекомендуется просматривать 1 раз в неделю за необходимое количество рабочих

дней.

3.2.2.7. Проверка консистентности индексов ПП.

Проверка консистентности индексов выполняется:

a) При возникновении жалоб на работу поиска, после анализа отчета Indexing Metrics и User

Activity Report,

b) При возникновении ошибок в логах xhive (instances – Logging – xdb) с ошибками на сбои

сегментов базы данных,

c) При восстановлении индексов из резервной копии.

Проверка консистентности выполняется через панель управления xPlore – Data

Management – кнопка Check DB Consistency.

40

При большом размере индексов, операция может занимать от 1 часа до нескольких часов.

При нарушении консистенции индексов, рекомендуется выполнить восстановление базы

индексов из резервной копии и доиндексацию дельты.

3.2.2.8. Проверка целостности и соответствия ПП.

В результате различных сбоев может быть выявлено нарушение целостности и

соответствия индекса. Причиной подобного нарушения может быть – временная

неработоспособность индекс-агента, проблемы в работе КСПД (сети) и т.д.

В случае обнаружения проблем (жалобы на осутствие в результатах поиска новых

документов, разрастание очереди на индексацию) требуется:

a) Провести регламентные работы по чистке очереди dmi_queue_items от устаревших

объектов dm_fulltext_index_user. Не рекомендуется чистка удалением через sql или dql,

если число подобных объектов превышает 100 тыс. Требуется корректная операция по

пересозданию новой таблицы dmi_queue_item_s в СУБД,

b) Восстановить федерацию \ домен коллекции индексов,

c) Восстановить работу индекс-агента,

d) Запустить средство проверки целостности и соответствия индекса -

/dm/xPlore/setup/indexagent/tools/ftintegrity_for_****.sh. Запуск проверки рекомендуется

выполнять в нерабочее время,

e) После окончания работы ftintegrity проверить число объектов в файле ObjectId-

dctmOnly.txt, если число объектов менее 200 тыс, то скопировать данный файл на

индексацию:

cp ObjectId-dctmOnly.txt

/dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/deployments/IndexAgent.war/WEB

-INF/classes/ids.txt

Если число объектов в файле превышает 200 тыс,, рекомендуется разбиение файла на части по

200 тыс и загрузка по очереди с интервалом 2 часа.

41

Работу ftintegrity можно автоматизировать запуском 1 раз в неделю в выходные с помощью

cron, а также автоматическую доиндексацию.

3.2.2.9. Резервное копирование и восстановление ПП.

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

остановленном индекс-агенте, если число суточных операций по отчету User Activity Report

превышает 50 тысяч, и число обрабатываемых в сутки документов превышает 500 000 в сутки по

отчету Indexing Metrics. Резервное копирование выполняется средствами dsearch и только при

запущенном сервисе DctmServer_PrimaryDsearch, так как идет обращение к xdb.

Резервное копирование небольшого объема индексов (до 500 ГБ) можно выполнять

уровнем федерации (полное) и домена (инкрементальное). Выполнение инкрементального

резервного копирования чаще, чем 1 раз в сутки не рекомендуется, для построения

детальной схемы резервного копирования необходимо производить анализ объема данных и

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

восстановления.

Резервное копирование:

./xplore.sh "backupFederation 'путь к резервной копии', false, null" >>путь к логу.log

./xplore.sh "backupDomain 'путь к резервной копии', false, null" >>путь к логу.log

Для создания целостной полной резервной копии требуется так же резервировать данные

из директорий:

/dm/xPlore/config/

/dm/xPlore/dsearch/

/dm/xPlore/setup/

Холодное резервное копирование выполняется при остановленных сервисах ПП,

необходимо убедиться, что база данных xdb остановлена и нет работающих процессов java, иначе

данные индексов будут неконсистентны.

Восстановление коллекций индексов выполняется по стандартной схеме GF-F (федерация

– домен).

./xplore.sh "restoreFederation 'путь к резервной копии федерации'"

./xplore.sh "restoreDomain 'путь к резервной копии федерации'"

3.3. Обновление комплекса

3.3.1. Общие замечания по процедуре обновления компонентов комплекса ЕОСДО.

Установка обновлений прикладного ПО производится в соответствии с документацией

производителя ПО. Для бесперебойной работы комплекса ЕОСДО должны быть полностью

отключены механизмы автоматического обновления системного ПО, прикладного ПО и любого

42

стороннего ПО, участвующего в работе комплекса. Установка обновлений должна

осуществляться только после проверки на второстепенных средах (тестирования и разработки).

Настоящий регламент не рассматривает процедуру обновления микропрограмм

аппаратного комплекса.

Процедура обновления может быть произведена только после разработки Плана

проведения работ, включающего:

Подробное описание подготовительных работ для проведения обновления,

Пошаговое описание шагов выполнения обновления,

План тестирования функционала системы после обновления,

Детальный план возврата системы в исходное состояние при неудачном выполнении работ.

Каждый их этапов плана должен иметь заданные временные рамки выполнения и

ответственных за выполнение работ специалистов.

Установка обновлений осуществляется в строгом соответствии с документацией вендора

компонента комплекса. Дополнительные рекомендации могут быть даны разработчиком системы

ЕОСДО после тестирования на второстепенных средах.

3.3.2. Установка минорных обновлений.

Установка минорных обновлений (патчей, исправлений) осуществляется:

Для ОС Red Hat Enterprise Linux – исключительно после использования команды «yum

check-update», построения списка версий пакетов, для которых имеются обновленные

версии и согласование перечная обновляемых пакетов с разработчиком системы ЕОСДО.

Установка обновлений пакетов без согласования версий может привести к нарушению

работоспособности комплекса.

Для IBM WebSphere – установка обновлений предусматривается для случаев, когда

применение исправления рекомендовано производителем для решения конкретной

проблемы в функционировании комплекса. Установка обновлений должна быть

согласована с разработчиком ЕОСДО.

Для продуктов OpenText Documentum – установка патчей выполняется только по

рекомендации службы поддержки вендора или по рекомендации разработчика системы

ЕОСДО. Установка осуществляется строго в соответствии с Patch Notes для конкретного

продукта OpenText Documentum. При наличии в патче обновления ПО стороннего вендора

(например, JDK или WildFly) требуется проведение дополнительной проверки на

второстепенных средах и привлечение разработчиков ЕОСДО для согласования проведения

обновления ПО.

Для Oracle Database – установка обновлений предусматривается для случаев, когда

применение исправления рекомендовано производителем СУБД для решения конкретной

проблемы в функционировании комплекса или задействованию нового функционала БД,

согласованного с эксплуатантом Системы. Установка обновлений должна быть согласована

с разработчиком ЕОСДО.

Установка минорных обновлений выполняется исключительно для одного компонента

комплекса (ОС, СУБД, Сервер приложений, Контент сервер и т.д.) в одну итерацию. Перед

43

проведением работ по обновлению системы выполняется полное резервное копирование

компонент, в отношении которых производятся работы.

3.3.3. Установка мажорных обновлений.

Установка любых мажорных обновлений (сервис пак, версия, релиз) осуществляется

после согласования версии обновленного ПО с матрицей совместимости прочих компонент

комплекса ЕОСДО. Так как комплекс представляет собой сложную архитектуру, в которой

используется ПО нескольких вендоров, требуется согласование используемых версий продуктов

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

(например, ОС, СУБД) рекомендуется рассмотреть возможность использования stage окружений

(КТС временного размещения клона обновляемой системы). При масштабном обновлении

компонент комплекса ЕОСДО (более чем одной версии компонента одного типа) требуется

подготовка и согласование документа-стратегии выполняемых работ.

Установка мажоритарных обновлений осуществляется:

Для ОС Red Hat Enterprise Linux – обновление версии ОС осуществляется в соответствии с

рекомендациями производителя ОС, и после согласования с разработчиком ЕОСДО.

Для IBM WebSphere – установка обновлений должна быть согласована с разработчиком

ЕОСДО.

Для продуктов OpenText Documentum – обновление выполняется по рекомендации службы

технической поддержки производителя ПО или разработчика ЕОСДО. Обновление

ключевых компонент комплекса (контент сервер, версия приложения) выполняется в

обязательном порядке с использованием stage окружения, максимально приближенного по

конфигурации к среде Промышенной эксплуатации, так как второстепенные среды имеют

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

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

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

Для Oracle Database – установка обновлений предусматривается для случаев, когда

применение исправления рекомендовано производителем СУБД для решения конкретной

проблемы в функционировании комплекса или задействованию нового функционала БД,

согласованного с эксплуатантом Системы. Установка обновлений должна быть согласована

с разработчиком ЕОСДО. Обновление выполняется в обязательном порядке с

использованием stage окружения, максимально приближенного по конфигурации к среде

Промышенной эксплуатации, так как второстепенные среды имеют редуцированную

(минимальный набор компонентов) схему развертывания и не предполагают использование

функций ПО, связанных с обеспечением распределения нагрузки или обеспечением

высокой доступности.

Установка мажорных обновлений выполняется исключительно для одного компонента

комплекса (ОС, СУБД, Сервер приложений, Контент сервер и т.д.) в одну итерацию, за

исключением случаев, когда обновление одного компонента требует обновление одного или

нескольких для соблюдения требований матрицы совместимости. Перед проведением работ по

обновлению системы выполняется полное резервное копирование компонент, в отношении

которых производятся работы.

44

3.3.4. Установка обновлений на клиентские рабочие станции.

Автоматическое обновление на клиентских рабочих станциях должно быть отключено.

При произведении работ по установке обновлений необходимо согласование устанавливаемых

версий обновлений с разработчиком ЕОСДО для:

Версий браузера.

Установка патчей безопасности, системных драйверов выполняется согласно внутренней

политике ИС АО «Гринатом».

3.4. Мониторинг ЕОСДО

Администратор Системы должен контролировать свободное доступное пространство на

файловых системах, а также регулярно (не менее 1 раза в день) отслеживать предупреждения и

критические ошибки в следующих системных журнальных файлах:

на серверах приложений и метод сервере:

$WS_PROFILEDIR/<PROFILE>/logs/<AS_NAME>;

$WS_INSTALLDIR/logs/app;

на контент-серверах:

$DOCUMENTUM/dba/log,

$DOCUMENTUM_SHARED/wildfly11.0.1/server/DctmServer_MethodServer/log;

на сервере индексирования:

$XPLORE_HOME/wildfly11.0.1/server/DctmServer_PrimaryDsearch/logs;

$XPLORE_HOME/wildfly11.0.1/server/DctmServer_Indexagent/logs;

на серверах балансировки нагрузки:

/var/log/nginx.

4. Ошибки работы системы и способы их устранения

4.1. Вход в Систему невозможен из-за ввода неправильного имени


При входе в Систему отказ в доступе возможен по причине неправильно введенного

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

что на странице входа указан корректный домен для аутентификации.

4.2. Отображение окна сертификата при работе с Системой

При запуске Системы на экране может отобразиться окно сертификата безопасности,

которое изображено на рисунке 1. Для закрытия данного окна следует нажать кнопку ,

после чего окно больше не появится.

Рисунок 1 − Окно сертификата безопасности 1

4.3. Возможные ошибки при возобновлении работы с Системой после

временного интервала

Следует учитывать, что в Системе запускается автоматический учет времени простоя,

если авторизованный пользователь длительное время не работает с Системой. При возобновлении

деятельности возможно появление сообщений «Тайм-аут по простою», которые означают, что

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

выполнить повторную авторизацию в Системе.

Длительность допустимого простоя задается в файле-дескрипторе /WEB-INF/web.xml,

находящемся внутри war-файла приложения Системы. Для изменения значения необходимо

отредактировать секцию <session-config>.<session-timeout>, установив требуемое значение (в

46

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

параметра на постоянной основе необходимо изменить файл в коде Системы (GIT).

4.4. Возможные ошибки при возврате на предыдущую страницу браузера с

помощью кнопки Back

При работе с Системой запрещается использовать кнопку управления «Back» (Назад) в

браузере Internet Explorer или Chrome, так как это может привести к появлению ошибок и потере

вводимых данных.

Для перемещения между справочниками следует использовать дерево папок в левой

панели интерфейса Системы.

При перемещении между различными уровнями иерархических справочников следует

использовать путь к выбранному элементу в верхней части правого фрейма, щелкнув по

которому, можно вернуться на более высокий уровень дерева.

При открытии плоских справочников, на странице отображаются первые пянадцать

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

кнопкой мыши на одну из экранных кнопок перемещения между страницами .

4.5. Возможные ошибки при открытии файлов

Возможны 2 варианта развития событий при открытии файлов:

1. Уведомление «Запускается приложение работы с контентом. Повторите через

минуту.» - означает, что приложение не успело запуститься для открытия файла,

нужно подождать минуту и попробовать снова.

2. Ошибка «Не удалось запустить приложение для работы с контентом.» - появляется

спустя какое-то время после первой попытки открытия файла.

В случае возникновения ошибки при загрузке или открытии файлов на компьютере

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

1) Убедиться, что установлены и используются корректные версии операционной

системы, Internet Explorer или Chrome и среды выполнения Java (Sun JRE).

2) Убедиться, что адрес приложения добавлен в зону «Надежные сайты» и для него не

блокируются всплывающие окна в Internet Explorer (если используется браузер

Internet Explorer).

3) Закрыть все окна Internet Explorer или Chrome, при необходимости, завершить в

Диспетчере Задач Windows все процессы iexplore.exe, java.exe и javaw.exe, если

система открыта в Internet Explorer, и все процессы chrome.exe и jp2launcher.exe,

если используется Chrome.

4) Убедиться, что адрес https://url /записан в Exeption Site List в консоли Java. Для этого

нужно открыть Java Control Panel из «Панели управления», перейти на закладку

Security.

47

5) Отключить, если используются, брандмауэр, антивирус и дополнительные средства

защиты, затем попробовать воспроизвести проблему. Если не воспроизводится,

необходимо тщательно проанализировать текущие настройки антивирусного ПО и

брандмауэра и настроить те из них, которые приводят к препятствованию работы

функционала апплета передачи содержимого в Webto

Далее, для диагности проблемы:

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

сообщение системы о проблеме с запуском:

a. Нужны подробные сведение помимо шибки Java (в том числе, недоверия

сертификату);

b. Сообщение «Подождите минуту» - оповещение, а не ошибка.

2. Если проблема на АРМП:

2.1. Отправить пользователю архив 1_EOSDOSupportGenerator.7z

2.2. Попросить пользователя запустить вложенный в него скрипт и выслать обратным письмом

результат (оно будет сгенерировано автоматически);

2.3. На основании полученной информации запросить у ЦПП или пользователя (в зависимости от

необходимых прав доступа) выполнить необходимые шаги инструкции (в отчете будут указаны

номера проблемных пунктов).

2.4. Если вопрос касается сертификатов ГК (п.3.7)

a. ЦПП направить архив 2_certImport.7z

b. Запросить у ЦПП лог отработки или попросить их самостоятельно удостовериться,

что все настроено корректно

2.5. После исправления ЦПП настроек АРМП, повторить п.2.2.

5. Аварийные ситуации и действия по их устранению

Таблица 11. Перечень действий администраторов при сбоях компонент ЕОСДО.

Сервис Вид сбоя Последовательность действий

для диагностики сбоя Последовательность действий при сбое

Сервер

приложений

Недоступно

приложение

ЕОСДО

Проверить доступность узлов

серверов приложений

1) Вывести узел из-под балансировщика нагрузки

echo "disable server имя_балансировщика(backend)/имя сервера в

конфигурации HAProxy(server)" | socat stdio /var/run/haproxy.sock

2) Собрать журналы (логи) узла для анализа

3) Исследовать логи с целью выявления причины сбоя

4) Устранить причину сбоя (проблема конфигурации, недостаток

ресурсов и т.д.)

5) Перезапустить узел сервера приложений согласно п. 3.1.3

6) Проверить доступность приложения

7) Вернуть узел под балансировщик нагрузки

echo "enable server имя_балансировщика(backend)/имя сервера в

конфигурации HAProxy(server)" | socat stdio /var/run/haproxy.sock

8) Предоставить пакет данных для анализа разработчикам (при

необходимости)

Сервер

Shark

Недоступно

приложение

Shark или

федеративные

прилоежния

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

сервера приложений Shark

1) Собрать журналы (логи) узла для анализа




4) Перезапустить узел сервера приложений согласно п. 3.1.3

5) Проверить доступность приложения

6) Вернуть узел под балансировщик нагрузки



49



Недоступен

сервис Apache

MQ

Проверить статус сервиса и

наличие процесса на сервер (ps –

ef | grep activemq)

1) Собрать журналы (логи) activemq для анализа




4) Перезапустить activemq (service activemq restart от root)




сервер базы

данных

федерации

(MongoDB

4.0)

Проверить доступность и

работоспособность базы

данных MongoDB 4.0.

1) Собрать журналы (логи) сервера для анализа в файлах логов и

mongo Shell




4) Перезапустить сервер MongoDB 4.0 (service mongod restart)

5) Проверить доступность (mongo –u, пользователь – p, пароль –

authenticationDatabase имя базы данных)



Контент

сервер


JMS

Проверить работоспособность

и доступность JMS (п. 3.2.1.4)

1) Собрать журналы (логи) JMS для анализа




4) Перезапустить JMS п.3.1.3



50




докброкер


и доступность докброкера (п.

3.2.1.4)

1) Собрать журналы (логи) докброкера для анализа




4) Перезапустить докброкер п.3.1.3




сервис



и доступность репозитория (п.

3.2.1.4), проверить

возможность подключения к

репозиторию средствами

IDQL, Documentum

Administrator

1) Собрать журналы (логи) сервиса репозитория для анализа




4) Перезапустить репозиторий п.3.1.3

5) Перезапустить приложения ЕОСДО



Полнотексто

вый поиск


индекс-агент


и доступность индекс-агента

(п. 3.2.1.4, 3.2.2.2, 3.2.2.3)

1) Собрать журналы (логи) индекс-агента для анализа




4) Перезапустить индекс-агент п.3.1.3


полнотекстовы

й поиск


и доступность dsearch (п.

3.2.2.2, 3.2.2.3)

1) Собрать журналы (логи) dsearch для анализа




4) Перезапустить сервисы полнотекстового поиска п.3.2.2.4



5.1. Восстановление работоспособности ЕОСДО

В данном разделе для каждого типа сбоя, указанного в подразделе 0, описывается

порядок выполнения операций для возвращения ЕОСДО в штатный режим работы.

5.1.1. Основные типы сбоев

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

остановка системной службы (тип 1);

повреждение, либо утеря данных - БД, файловое или индексного хранилище (тип 2);

5.1.2. Восстановление в случае остановки приложения

В случае возникновения сбоя типов 1 и 3 необходимо перезапустить процессы

Documentum в следующей последовательности:

остановить сервисы репозитория и сервер методов java на сервере контента;

остановить агент и сервер индексирования на сервере индексирования;

запустить сервисы репозитория и сервер методов java;

запустить агент и сервер индексирования.

При недоступности контент-сервера возможно появление ошибок:

DM_SESSION_E_CANT_CONNECT и DM_DOCBROKER_E_HOST_NAME. Если не доступен

сервер приложений или вся сеть, то возможно появление следующей ошибки: The page cannot be

displayed.

При сбоях репозитория (приложения docbase, docbroker и т.д.) в обязательном порядке

требуется рестарт приложений ЕОСДО!

5.1.3. Восстановление в случае повреждения данных

В случае сбоя в работе сервера СУБД необходимо восстановить БД из резервной копии

при помощи штатного средства ORACLE RMAN, встроенного в используемую систему

резервного копирования. Руководство по RMAN содержится в документе Oracle Database Backup

and Recovery Advanced User’s Guide.

Восстановление необходимо производить только при остановленных процессах

Documentum.

В случае сбоя в работе сервера контента или сервера приложений необходимо

восстановить файловое хранилище из резервной копии. Восстановление производить при

остановленных процессах Documentum.

52

В случае серьезного сбоя в работе сервера поиска необходимо восстановить индексное

хранилище из резервной копии. Восстановление производить при остановленных процессах

Documentum.

Восстановлением данных занимается ОБИС - Отдел базовых информационных сервисов.

5.1.4. Полное восстановление

При выходе из строя аппаратных компонентов сервера, критическом сбое в работе ОС,

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

следующие действия (в зависимости от роли сервера):

1) Восстановление сервера СУБД:

а) восстановить работу аппаратного обеспечения сервера БД;

б) установить системное и прикладное ПО;

в) восстановить БД из резервной копии.

2) Восстановление сервера контента:

а) восстановить работу аппаратного обеспечения сервера контента;

б) установить системное ПО;

в) установить прикладное ПО;

г) восстановить файловое хранилище из резервной копии.

3) Восстановление сервера индексирования:

а) восстановить работу аппаратного обеспечения сервера поиска;


в) установить прикладное ПО;

г) восстановить индексное хранилище из резервной копии.

4) Восстановление сервера приложений:

а) восстановить работу аппаратного обеспечения сервера приложений;


в) установить прикладное ПО.

В системе предусмотрено частичное и полное восстановление прикладных данных.

1. Полное восстановление продуктивных прикладных данных, восстановление всех данных

контента и соответствующих им метаданным, хранящимся в БД Oracle, на конкретный день

недели, на одну или две недели, или один месяц назад от текущего момента («откат» назад на

сутки и более от текущего момента) осуществляется следующим образом:

o администратором выполняется остановка служб прикладной системы ЕОСДО;

53

o восстановление контента проводится с помощью имеющихся ленточных или дисковых

копий (которые делаются ежедневно, еженедельно и ежемесячно):

сначала восстанавливается полная ленточная \ дисковая копия, а затем

необходимое количество инкрементальных;

o восстанавливается полная ленточная \ дисковая копия БД Oracle (делается ежедневно,

еженедельно и ежемесячно);

o далее администратором выполняется запуск служб системы ЕОСДО, проверка данных

контента и СУБД.

2. Частичное восстановление продуктивных прикладных данных, а именно, восстановление

отдельного документа, на конкретный день недели, на одну или две недели, или один месяц

назад от текущего момента («откат» назад на сутки и более от текущего момента)

осуществляется следующим образом:

o восстановление продуктивных данных производится на временно выделенный

ресурсный пул Vmware (должен быть изолирован по сети от продуктивной среды);

o проводится восстановление продуктивного контента с помощью имеющихся

ленточных \ дисковых копий (которые делаются ежедневно, еженедельно и

ежемесячно):

сначала восстанавливается полная ленточная \ дисковая копия, а затем

необходимое количество инкрементальных (в хранилище тестовой среды);

возможно восстановление отдельного раздела СХД;

o восстанавливается полная ленточная копия продуктивной БД Oracle (делается

ежедневно, еженедельно и ежемесячно) в БД среды тестирования, в базе данных

изменяются параметры в таблице dm_location_s для области хранения контента;

o вручную выполняется реконфигурация для назначения требуемых адресов и имен

серверов (IP адрес сервера, FQDN сервера), а также конфигурации развернутых

сервисов;

o администратором выполняется запуск служб системы ЕОСДО на восстановленной

среде, проверка данных контента и БД Oracle;

o администратором выполняется поиск нужного документа, экспорт документа из

временной среды и импорт в продуктивный ландшафт.

54

После восстановления прикладных данных рекомендуется в ПО Documentum запускать

задание dm_ConsistencyChecker с целью выявления неконсистентных, поврежденных данных.

3. Восстановление прикладных данных ландшафта тестирования и разработки выполняется

полностью аналогично описанному выше процессу восстановления прикладных данных

продуктивного ландшафта.

4. Восстановление системных данных серверов всех ландшафтов производится с дисковых

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

восстановления серверов «с нуля»:

o сервер загружается через сеть;

o производится восстановление ОС сервера, системных дисковых разделов;

o полностью восстанавливаются системные данные с последней резервной копии.

5. Восстановление серверов среды виртуализации производится в следующем порядке:

o восстановление VMware ESX сервера;

o восстановление сервера управления виртуальной средой VMware;

o восстановление конфигурации виртуальной среды

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

6. Порядок восстановления серверной среды при невозможности восстановления из резервной

копии:

a. Восстановление сервера СУБД:

Подготовить виртуальный сервер в соответствии с конфигурацией для

конкретного ландшафта;

Установить системное ПО (ОС и СУБД);

Сконфигурировать сервер СУБД или кластер серверов СУБД (в зависимости от

назначения ландшафта)

Восстановить базу данных из резервной копии

b. Восстановление сервера контента:

Подготовить виртуальные серверы для OpenText Documentum и NFS.

55

Установить системное ПО (ОС);

Восстановить параметры окружения;

Установить прикладное ПО (OpenText Documentum Content Server);

Сконфигурировать сервер контента и NFS в зависимости от назначения

ландшафта

Восстановить конфигурацию сервисов контента (параметры установки

прикладного ПО) из резервной копии

c. Восстановление сервера приложений:

Подготовить виртуальный сервер;

Установить системное ПО (ОС);

Сконфигурировать сервер приложений или группу серверов приложений в

зависимости от назначения ландшафта;

Восстановить параметры окружения;

Восстановить конфигурацию прикладных приложений (папки с приложениями)

из резервной копии.

56

6. Список Job и их параметры

6.1. Системные сервисы (JOB) и расписание их запуска

В настоящий момент системные сервисы Системы запускаются приложением rosatom-shark-quartz. Конфигурация этих джоб выполняется

в коде Системы и пакуется в war-файле приложения (по пути WEB-INF/classes/spring).

Таблица 12. Системные сервисы (JOB) и расписание их запуска.

Название Модуль Описание Способ реализации

(job или job+servlet)

Режим

запуска

Акти

вен

NotificationBalancerJob Базовый

блок

Балансировка очередей нотификаций.

Запускается с помощью

NotificationBalancerJobTrigger

Приложение rosatom-

shark-quartz

0 0/5 * * * ?1

Да

1 Режим запуска сервисов для приложения rosatom-shark-quartz задается в конфигурационных файлах самого приложения

57



Режим

запуска

Акти

вен

NotificationJob Базовый

блок

Отправка нотификаций.

Балансировщики:

NotificationJobTrigger_1










Запускается с помощью NotificationJobTrigger


shark-quartz

0 0/15 * * * ?

Да

updateMonitorJob Базовый

блок

Монитор-Актив репликация обновлений.

Запускается с помощью updateDataTriger


shark-quartz

0 0 20 * * ?

Да

replicateDictionaryJob Базовый

блок

Монитор-Актив репликация справочников.

Запускается с помощью replicateDictionaryTriger


shark-quartz

0 0 20 * * ?

Да

replicateDocumentJob Базовый

блок

Монитор-Актив репликация документа.

Запускается с помощью replicateDocumentTrigger


shark-quartz

0 30 21 * * ?

Да

defaultApproveDocume

ntJob

Базовый

блок

Согласование по умолчанию.


defaultApproveDocumentTrigger


shark-quartz

0 40/50 * * * ?

Да

58



Режим

запуска

Акти

вен

processServiceRequestsJ

ob

Базовый

блок

Обработка сохраненных запросов к веб-сервисам.


processServiceRequestsTrigger


shark-quartz

0/30 * * * * ?

Да

periodicCommissionJob Базовый

блок

Периодические поручения.

Запускается с помощью periodicCommissionTrigger


shark-quartz

0 30 06 * * ?

Да

PeriodicNotificationGen

eratorJob

Базовый

блок

Генератор периодических нотификаций.


PeriodicNotificationGeneratorJobTrigger


shark-quartz

0 0 8,13 * * ?

Да

ServiceDeskNotification

Job

Базовый

блок

Отправка запросов в техподдержку.


ServiceDeskNotificationJobTrigger


shark-quartz

0 0/3 * * * ?

Да

ExchangeBy51Controlle

rJob

Обмен Распределение нагрузки по джобам сценария 5.1.


ExchangeBy51ControllerTrigger


shark-quartz

55 1/02 * * * ?

Да

59



Режим

запуска

Акти

вен

ExchangeBy51Performe

rJob

Обмен Выполнения сценария 5.1 в заданной очереди.

Балансировщики:

ExchangeBy51PerformerTrigger01











ExchangeBy51PerformerTrigger


shark-quartz

0 0/02 * * * ?

Да

Мониторинг состояния системных сервисов: Мониторинг состояния самих системных сервисов производится через Documentum

Administrator. Если системный сервис при последней отработке корректно завершался, то это отражено в его статусе. При корректной работе на

карточке системного сервиса в поле LAST STATUS должно отображаться «Completed», а также должно быть заполнено время последнего

выполнения (поле LAST RUN). Поле STATE системного сервиса должно быть «Active».

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

Running и не останавливается, следует пользоваться способом из инструкции http://documentum-emc.blogspot.it/2012/04/how-to-unlock-job-in-

running-state.html. Дождаться автоматического запуска системного сервиса. В критическом варианте – перезапустить метод-сервер. Дождаться

автоматического запуска системного сервиса

http://documentum-emc.blogspot.it/2012/04/how-to-unlock-job-in-running-state.html

http://documentum-emc.blogspot.it/2012/04/how-to-unlock-job-in-running-state.html

60

6.2. Параметры системных сервисов (JOB)

Таблица 13. Параметры системных сервисов (JOB)

Название Источник данных в

БД

Восстановл

ение Входные параметры

Логирован

ие Примечание

croc_PeriodicNotific

ation

view

croc_notifiable_tasks,

которая выбирает

задачи со сроком

исполнения

Не

требуется

COMMISSION_NOTIFICATI

ON_PERIODS -

количество дней, за

которое надо отсылать

уведомления;

-SERVLETS_TIMEOUT –

таймаут сервлета;

-SERVLETS_URL – адреса

запускаемых сервлетов

По

умолчанию

При перезапуске системного сервиса,

и повторном вызове будут

обработаны только последние задачи

за период времени, а не весь объем

данных

https://blog.croc.ru/display/documentum65/croc_PeriodicNotification

https://blog.croc.ru/display/documentum65/croc_PeriodicNotification

61


БД



Логирован


croc_checkscanconte

nt

com.croc.documentum.ro

satom.

methodserver.method.

CheckScanContentMetho

d.Query.

ATTACHMENTS_SCA

NNED_ONLY

Не

требуется

Для регулирования нагрузки на

системный сервис в параметрах

системного сервиса существует

возможность задавать перечень

кодов предприятий, сделки от

которых обрабатывает данный

системный сервис, например:

BAR_CODES1 000010;

BAR_CODES2 000020;

BAR_CODES3 000030.

Значения «000010», «000020»,

«000030» - первые цифры

штрих-кода, которые являются

кодом предприятия (кодом

учетной системы).

Если в Job Properties для

Method Arguments значения не

заданы, фильтра по учетным

системам нет – системный

сервис обрабатывает все

сделки.

Для распараллеливания

системных сервисов

существует возможность

создавать второй (третий и т.д.)

экземпляр системного сервиса

и для каждого системного

сервиса указывать те коды,

сделки которых должен

обрабатывать этот экземпляр.

При создании экземпляров

Отдельно с

уровнем

DEBUG в

файл erp-

integration.l

og

На момент составления описания:

select distinct r_object_id from

croc_document_attachment a

where is_scanned_only = TRUE and

document_id = '0000000000000000'

and exists ( select r_object_id from

croc_document_common b where

a.title = b.r_object_id)

Ищет и обрабатывает все сканы,

вложенных в документы (создает

задания на проверку

отсканированных файлов).

Достаточно ресурсоемкая операция,

обрабатывается около 2 тысяч

вложений.

Ограничения по времени нет, но

учитывая что обрабатываются

небольшие объемы записей,

удаление из выборки

нецелесообразно

http://blog.croc.ru/display/documentum65/croc_checkscancontent


62


БД



Логирован


croc_NotificationDel

ivery

croc_notification по

флагу is_delivered

Не

требуется

-THREAD_COUNT –

количество потоков

обработки;

-SEND_TIMEOUT – время

отправки одного письма

По

умолчанию

Увеличение количества потоков

обработки увеличивает скорость

обработки очереди неотправленных

нотификаций. По умолчанию

используется два потока.

Время отправки задает промежуток

времени по истечении которого

отправка прерывается, и считается

что сессия неактивна и создается

новая для следующих нотификаций.

По умолчанию 60 секунд на письмо.

Довольно ресурсоемкая задача, так

как в день в среднем создается

порядка 100 тысяч нотификаций

croc_ExpiredDealNo

tification

dm_dbo.check_deal_task

s_view

Не

требуется

Нет По

умолчанию

Создает нотификации. Отправкой

нотификаций не занимается.

croc_AutoDealCreat

ion

croc_deal_register Не

требуется

Нет По

умолчанию

Обрабатывает несколько десятков

записей

croc_JobLoadIncom

eDocuments

- Не

требуется

Нет По

умолчанию

http://blog.croc.ru/display/documentum65/croc_NotificationDelivery

http://blog.croc.ru/display/documentum65/croc_NotificationDelivery

http://blog.croc.ru/display/documentum65/croc_ExpiredDealNotification

http://blog.croc.ru/display/documentum65/croc_ExpiredDealNotification

http://blog.croc.ru/display/documentum65/croc_AutoDealCreation

http://blog.croc.ru/display/documentum65/croc_AutoDealCreation

http://blog.croc.ru/display/documentum65/croc_JobLoadIncomeDocuments

http://blog.croc.ru/display/documentum65/croc_JobLoadIncomeDocuments

63


БД



Логирован


croc_unlockdocume

nt

croc_lock Не

требуется

Входные параметры:

APPLICATION_URL – адрес

запуска метода.

Параметры работы:

lockDateTo Разрешенный

срок блокировки (формат

‘dd.MM.yyyy’). При

отсутствии берется

максимальный срок

блокировки документа

через

RepositoryConfiguration;

lockOwnerId Идентификатор

владельца блокировки, при

отсутствии не участвует в

запросе в качестве

критерия

- Обрабатывает блокировки, у

которых дата создания меньше

определенной даты.

При падении или длительном

отсутствии запуска обработает

записи за пропущенное время.

Разблокировка происходит через

LockService. Сервис служит в

качестве надстройки, фактическое

удаление объекта происходит через

интерфейс

IDfPersistentObject.destroy()

croc_ContractCancel

lation

dm_dbo.croc_signing_co

ntracts

Не

требуется

Нет По

умолчанию

Обрабатывает записи за последние

MAXIMUN_AFTER_SIGN_DAYS_

WAIT дней.

На момент описания

MAXIMUN_AFTER_SIGN_DAYS_

WAIT = 90 дней.

При запуске после длительного

простоя будет обработано больше

документов, чем обычно

http://blog.croc.ru/display/documentum65/croc_unlockdocument

http://blog.croc.ru/display/documentum65/croc_unlockdocument

http://blog.croc.ru/display/documentum65/croc_ContractCancellation

http://blog.croc.ru/display/documentum65/croc_ContractCancellation

64


БД



Логирован


croc_PeriodicComm

ission

croc_periodic_commissio

n

Не

требуется

Нет По

умолчанию

Обрабатывает записи, которые

находятся в статусе

CommissionLifeCyclePolicyModel.

LifeCycleStateName.EXECUTE

При отсутствии запуска или сбоя

периодические поручения не

пересоздаются

croc_JobUnloadDoc

uments

- Не

требуется

Нет По

умолчанию

Обрабатывает по 128 записей за один

запуск

croc_UpdateSubstitu

teGroup

- Не

требуется

Нет По

умолчанию


запуск

croc_TruncateSubsti

tuteHistory

- Не

требуется

Нет По

умолчанию


запуск

http://blog.croc.ru/display/documentum65/croc_PeriodicCommission

http://blog.croc.ru/display/documentum65/croc_PeriodicCommission

http://blog.croc.ru/display/documentum65/croc_JobUnloadDocuments

http://blog.croc.ru/display/documentum65/croc_JobUnloadDocuments

http://blog.croc.ru/display/documentum65/croc_UpdateSubstituteGroup

http://blog.croc.ru/display/documentum65/croc_UpdateSubstituteGroup

http://blog.croc.ru/display/documentum65/croc_TruncateSubstituteHistory

http://blog.croc.ru/display/documentum65/croc_TruncateSubstituteHistory

65


БД



Логирован


croc_repositorydatae

xchange

crc_repodataexch_out_qu

eue

Не

требуется

1) -

PROCESSING_QUEUE_SIZE -

количество обрабатываемых

сообщений за один запуск

джоба (по умолчанию «500»);

2) -THREAD_COUNT -

количество одновременно

обрабатываемых сообщений

(многопоточность) (по

умолчанию «1» - является

рекомендуемым значением, так

как увеличение этого параметра

приводит к увеличению

потребляемых системой

ресурсов).

По

умолчанию

Обрабатывает

croc_case_pass_hist

ory

croc_arch_doc_pass_hist. Не

требуется

Нет По

умолчанию

Создает на основании данных

уведомление и нотификацию

croc_warrant_notific

ations

croc_document_warrant Не

требуется

Нет По

умолчанию

Создает нотификации и уведомления

по доверенностям

croc_DutyPaymentT

askCreator

croc_protection_duty Не

требуется

Нет По

умолчанию

Обрабатывает записи, у которых

Плановая дата более 60 дней от

текущей

http://blog.croc.ru/display/documentum65/croc_case_pass_history

http://blog.croc.ru/display/documentum65/croc_case_pass_history

http://blog.croc.ru/display/documentum65/croc_warrant_notifications

http://blog.croc.ru/display/documentum65/croc_warrant_notifications

http://blog.croc.ru/display/documentum65/croc_DutyPaymentTaskCreator

http://blog.croc.ru/display/documentum65/croc_DutyPaymentTaskCreator

66


БД



Логирован


croc_defaultapprovet

ype

Собирает задачи по

подразделению (если

стоит соответствующая

настройка в

справочнике).

Не

требуется,

при сбое

необходимо

запустить

повторно

Нет По

умолчанию

croc_JobLoadMedo

Notices

- Не

требуется

Нет По

умолчанию

croc_JobUnloadMed

oNotices

- Не

требуется

Нет По

умолчанию

croc_WorkDelegatio

n

croc_job Не

требуется

SERVLET_TIMEOUT –

таймаут сервлета;

APPLICATION_URL – адрес

сервера, на котором будет

запущена передача дел.

По

умолчанию

croc_cert_auth_notif

ications

croc_document_cert_auth

, croc_task

Не

требуется

Нет По

умолчанию

Не ресурсоемкая операция,

обрабатывается пару сотен записей.

Отвечает за автоматическое

закрытие документов

croc_license_nearby

_end

croc_document_license,

croc_lifecycle_policy

Не

требуется

Нет По

умолчанию


обрабатывается пару сотен записей.

Создает уведомления

http://blog.croc.ru/display/documentum65/croc_defaultapprovetype

http://blog.croc.ru/display/documentum65/croc_defaultapprovetype

http://blog.croc.ru/display/documentum65/croc_JobLoadMedoNotices

http://blog.croc.ru/display/documentum65/croc_JobLoadMedoNotices

http://blog.croc.ru/display/documentum65/croc_JobUnloadMedoNotices

http://blog.croc.ru/display/documentum65/croc_JobUnloadMedoNotices

http://blog.croc.ru/display/documentum65/croc_WorkDelegation

http://blog.croc.ru/display/documentum65/croc_WorkDelegation

http://blog.croc.ru/display/documentum65/croc_cert_auth_notifications

http://blog.croc.ru/display/documentum65/croc_cert_auth_notifications

http://blog.croc.ru/display/documentum65/croc_license_nearby_end

http://blog.croc.ru/display/documentum65/croc_license_nearby_end

67


БД



Логирован


croc_license_nuclear

_install

croc_document_license Не

требуется

Нет По

умолчанию


обрабатывается пару десятков

записей. Создает нотификации

croc_license_nuclear

_weapon

croc_document_license Не

требуется

Нет По

умолчанию



записей. Создает нотификации

croc_lodge_notificat

ions

croc_document_lodge Не

требуется

Нет По

умолчанию



записей. Рассылает уведомления

croc_ProtectionDoc

ValidInfo

croc_document_protectio

n

Не

требуется

Нет По

умолчанию



записей. Рассылает уведомления

croc_SessionNotific

ation

dm_dbo.as_notificationcr

eator_view

Не

требуется

Нет По

умолчанию



записей. Сами нотификации не

рассылает

croc_ActioAppealN

otification

dm_dbo.as_notificationcr

eator_view

Не

требуется

Нет По

умолчанию



записей. Сами нотификации не

рассылает

croc_comm_journal

_denorm

dm_dbo.croc_comm_jour

nal_denorm

Не

требуется

Нет По

умолчанию

Ресурсоемкая операция,


записей.

Оптимизации не подлежит

http://blog.croc.ru/display/documentum65/croc_license_nuclear_install

http://blog.croc.ru/display/documentum65/croc_license_nuclear_install

http://blog.croc.ru/display/documentum65/croc_license_nuclear_weapon

http://blog.croc.ru/display/documentum65/croc_license_nuclear_weapon

http://blog.croc.ru/display/documentum65/croc_lodge_notifications

http://blog.croc.ru/display/documentum65/croc_lodge_notifications

http://blog.croc.ru/display/documentum65/croc_ProtectionDocValidInfo

http://blog.croc.ru/display/documentum65/croc_ProtectionDocValidInfo

http://blog.croc.ru/display/documentum65/croc_SessionNotification

http://blog.croc.ru/display/documentum65/croc_SessionNotification

http://blog.croc.ru/display/documentum65/croc_ActioAppealNotification

http://blog.croc.ru/display/documentum65/croc_ActioAppealNotification

http://blog.croc.ru/display/documentum65/croc_comm_journal_denorm

http://blog.croc.ru/display/documentum65/croc_comm_journal_denorm

68


БД



Логирован


croc_checkscanconte

nt_01-06

com.croc.documentum.ro

satom.

methodserver.method.

CheckScanContentMetho

d.Query.

ATTACHMENTS_SCA

NNED_ONLY

Не

требуется

Является экземпляром

системного сервиса

croc_checkscancontent, описание

параметров см. в описании

croc_checkscancontent.

Отдельно с

уровнем

DEBUG в

файл erp-

integration.l

og

На момент составления описания:

select distinct r_object_id from

croc_document_attachment a

where is_scanned_only = TRUE and

document_id = '0000000000000000'

and exists ( select r_object_id from

croc_document_common b where

a.title = b.r_object_id)

Ищет и обрабатывает все сканы,

вложенных в документы (создает

задания на проверку

отсканированных файлов).

Достаточно ресурсоемкая операция,


вложений.

Ограничения по времени нет, но

учитывая, что обрабатываются

небольшие объемы записей,

удаление из выборки

нецелесообразно

croc_JobLoadMED

OMessages

- Не

требуется

Нет По

умолчанию

croc_ClearTrashAcl dm_dbo.trash_acl_ids_bu

lk_view

Не

требуется

Нет По

умолчанию

Выполняет наборы процедур,

которые очищают корзину ACL





http://blog.croc.ru/display/documentum65/croc_JobLoadMEDOMessages

http://blog.croc.ru/display/documentum65/croc_JobLoadMEDOMessages

http://blog.croc.ru/display/documentum65/croc_ClearTrashAcl

69


БД



Логирован


croc_allocateworkde

legation

- Не

требуется

SERVLET_TIMEOUT

"Timeout сервлета"(по

умолчанию 3 минуты);

APPLICATION_URL "URL

приложения"

(множественное значение)

По

умолчанию

Пример:

-SERVLET_TIMEOUT 10, -

APPLICATION_URL

http://localhost:7777/rosatom2/, -

APPLICATION_URL

http://localhost:7777/rosatom3/

croc_contractactivati

oncopyincase

- Не

требуется

Нет По

умолчанию

croc_ViolationPerio

dicNotification

- Не

требуется

Нет По

умолчанию

mtd_NdPeriodicNoti

ficationMethod

- Не

требуется

Нет По

умолчанию

http://blog.croc.ru/display/documentum65/croc_allocateworkdelegation

http://blog.croc.ru/display/documentum65/croc_allocateworkdelegation



http://blog.croc.ru/display/documentum65/croc_contractactivationcopyincase

http://blog.croc.ru/display/documentum65/croc_contractactivationcopyincase

http://blog.croc.ru/display/documentum65/croc_ViolationPeriodicNotification

http://blog.croc.ru/display/documentum65/croc_ViolationPeriodicNotification

http://blog.croc.ru/display/documentum65/mtd_NdPeriodicNotificationMethod

http://blog.croc.ru/display/documentum65/mtd_NdPeriodicNotificationMethod

70

VI Техническое решение по созданию, установке и настройке отдельной

инсталляции системы ЕОСДО на основе существующего решения

ОБЩИЕ СВЕДЕНИЯ

1.1 Термины, сокращения и определения

В данном документе использованы следующие термины и сокращения (см. Error!

Reference source not found.).

Таблица 2. Термины, сокращения и определения

Термин/сокращение Определение

ГК «Росатом» Государственная корпорация по атомной энергии «Росатом»

ДЗО Дочерние и зависимые общества

ЕОСДО Единая отраслевая система электронного документооборота

Ландшафт;

Системный

ландшафт

Группа взаимосвязанных систем, объединенных по признаку

функционального предназначения. В рамках данного Проекта

системные ландшафты могут быть представлены следующими

группами: разработка, тестирование, продуктив.

Перенос функциональности между ландшафтами Системы

осуществляется путем переноса релиза.

ОШС Организационно-штатная структура

Проект Проект «Система электронного документооборота для организаций

Госкорпорации «Росатом»»

ПО Программное обеспечение

Репозиторий Место, где хранятся и поддерживаются данные системы

Система ЕОСДО

ТЗ Техническое задание на выполнение работ по проекту «Система

электронного документооборота для организаций Госкорпорации

«Росатом»»

ТР Техническое решение по созданию, установке и настройке

отдельной инсталляции системы ЕОСДО на основе существующего

решения

ЦОД Центр обработки данных ГК «Росатом»

ФИО Фамилия, имя и отчество

71

1.2 Цель технического решения

Целью разработки данного технического решения является описание процесса создания,

установки и настройки отдельной инсталляции системы ЕОСДО на основе существующего

решения ЕОСДО, без клонирования репозитория ЕОСДО.

2 ПРИНЦИПЫ СОЗДАНИЯ ОТДЕЛЬНОЙ ИНСТАЛЛЯЦИИ

Отдельная инсталляция системы реализуется в соответствии со следующими принципами:

1) Система создается, устанавливается и настраивается на основе единого (действующего)

решения ЕОСДО на платформе OpenText Documentum версии 7.2.

2) Дистрибутив системы включает в себя: war-файл приложения системы rosatom-eosdo, war-

файл приложения для выполнения автоматических активностей rosatom-shark-quartz, war-

файл интеграционного приложения rosatom-shark-integration.war, zip-файл с артефактами

JMS rosatom-method-server (перечисленные артефакты аналогичны артефактам системы

ЕОСДО), а также пакет скриптов и утилит, выполнение которых позволит системе

функционировать в рамках сценариев, зафиксированных в ТЗ.

3) Для первоначального заполнения справочных данных в системе создается отдельная

программа (инсталлятор), которая позволяет автоматически заполнить начальные

справочные данные, необходимые для старта работы системы.

72

3 ПЕРЕНОС МОДЕЛИ ДАННЫХ DOCUMENTUM

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

объекты модели данных Documentum из существующей системы (в указанном порядке):

1. Типы данных (dm_type).

2. Форматы (dm_format).

3. Типы связей (dm_relation_type).

4. Группы и роли (dm_group).

5. Кабинеты (dm_cabinet).

6. Папки (dm_folder) с сохранением иерархии.

7. Наборы значений (dm_alias_set).

8. Методы (dm_method).

9. Джобы (dm_job).

10. Модули (dmc_module).

11. Библиотеки (dmc_java_library).

12. Jar-файлы (dmc_jar).

13. Зарегистрированные объекты базы данных (dm_registered).

При переносе групп исключить стандартные группы и группы, созданные для

конкретных подразделений (group_name содержит идентификаторы). При переносе групп в

рамках данного проекта использовался запрос:

select * from dm_group where (group_name like 'crc_%' or group_name like 'croc_%' or

group_name like 'ga_%') and group_name not like '%0b00012d%' and group_name not like

'%0c00012d%' and group_name not like '%1100012d%'

При переносе кабинетов и папок учесть, что в системе ЕОСДО многие справочные

объекты представлены типами-наследниками dm_folder. На данном этапе нужно исключить

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

пользователей. Нужно перенести кабинеты DICT и Root_Cabinet.

При переносе зарегистрированных объектов базы данных исключить перенос

стандартных объектов. В рамках данного проекта для переноса зарегистрированных объектов

использовался запрос:

select * from dm_registered where object_name not like 'dm_%' and object_name not like

'dmi_%'

Перенос объектов необходимо выполнить и для основного и для архивного репозиториев

(из основного репозитория в основной, из архивного репозитория в архивный).

73

В рамках данного проекта для переноса модели данных Documentum использовалась

утилита WASABI. Краткое описание утилиты приведено в пункте 0 данного документа.

4 ПЕРЕНОС СПРАВОЧНЫХ ОБЪЕКТОВ

Для функционирования новой инсталляции системы в рамках сценариев,

зафиксированных в ТЗ, необходимо перенести следующие справочные объекты* из

существующей системы (в указанном порядке):

1. croc_corporate_root (узел «Корпоративный архив»);

2. crc_dict_departments_root (корень для объектов ОШС);

3. croc_archive_org_root (корень для архивных папок);

4. crc_dict_org_positions (корень для объектов должностей);

5. crc_dict_users_root (корень для объектов пользователей);

6. crc_dict_chief_user_root (корень для объектов справочника подчиненности);

7. croc_inbox_kinds (справочник вариантов вида узла Задания/Уведомления);

8. crc_dict_inbox_doctype (справочник для фильтра «Тип документа» в узле

Задания/Уведомления);

9. crc_dict_deliv_type_root (корень для объектов справочника «Способы доставки»);

10. crc_dict_delivery_type (объекты справочника «Способ доставки»);

11. crc_dict_delivery_subtype (вложенные объекты справочника «Способ доставки)

12. crc_dict_dockind (корень для объектов шаблонов рег.номеров);

13. crc_dockind_group (типы и подтипы документов с шаблонами рег.номеров);

14. crc_dict_dockind_names_root (корень для объектов справочника «Наименования видов

документов»);

15. crc_dict_dockind_name (объекты справочника «Наименования видов документов»);

16. crc_dict_relations_root (корень для объектов справочника «Виды взаимосвязей»);

17. crc_dict_relation (объекты справочника «Виды взаимосвязей»);

18. crc_dict_urgent_param_root (корень для объектов справочника «Параметры срочности»);

19. crc_dict_urgent_param (объекты справочника «Параметры срочности»);

20. crc_dict_confer_type_root (корень для объектов справочника «Виды заседаний»);

21. crc_dict_conference_type (объекты справочника «Виды заседаний»);

22. crc_dict_object_root (корень для объектов справочника «Объекты»);

23. croc_confidential_types (объекты справочника «Доступ»);

24. crc_dict_role_info (объекты справочника «Виды конфиденциальности»);

25. crc_dict_commissions_root (корень для объектов справочника «Типовые поручения»);

26. ga_corp_question_kind_root (корень для объектов справочника «Виды корпоративных

вопросов»);

27. ga_corp_question_kind (объекты справочника «Виды корпоративных вопросов»);

28. croc_attachment_types (объекты справочника «Вид вложения»);

29. ga_attr_value_list (системные списки значений);

30. croc_policies_types (справочник политик доступа);

31. croc_card_config (настройки карточек системы);

32. ga_attachment_kind_root (корень для объектов справочника «Наименования видов

вложений»);

33. crc_dict_case_spec_root (корень для объектов справочника «Особенности дела»);

74

34. crc_dict_cases_root (корень для объектов справочника «Дела»);

35. crc_dict_case_type_root (корень для объектов справочника «Наименования типов дел»);

36. crc_dict_corrgroups_root (структура для объектов справочника «Группы рассылки по

корреспондентам»);

37. crc_dict_emplgroups_root (корень для объектов справочника «Управление группами»);

38. crc_dict_arch_heading_root (корень для объектов справочника «Рубрики архива»);

39. crc_dict_topic_root (корень для объектов справочника «Тематики»);

40. crc_dict_mailinggroups_root (корень для объектов справочника «Группы рассылки»);

41. crc_dict_addressees (корень для справочника «Корреспонденты»);

42. ga_hpsm_routing_table_root (корень для объектов справочника «Таблица маршрутизации

обращений»);

43. mr_template (шаблоны отчетов для системы «Отчеты»).

* - Список справочников может быть актуализирован по согласованию с Заказчиком.

5 ОПИСАНИЕ УТИЛИТЫ WASABI

Wasabi – это утилита инкрементной загрузки данных из источника в приемник. В качестве

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

Утилита представляет из себя запускаемый jar-файл.

В использованной реализации Wasabi могут быть выгружены (и загружены) следующие объекты

Documentum:

1. dm_alias_set

2. dm_format

3. dm_type

4. dm_relation_type

5. dm_group

6. dm_cabinet

7. dm_acl

8. dm_folder

9. dm_method

10. dm_job

11. dmc_module

12. dmc_jar

13. dm_registered

В качестве источника выгрузки объектов модели данных Documentum был использован

репозиторий Documentum тестовой системы ЕОСДО.

В текущей реализации Wasabi могут быть выгружены следующие справочники ЕОСДО:

1. croc_inbox_kinds

75

2. crc_dict_departments_root

3. croc_archive_org_root

4. crc_dict_org_positions

5. crc_dict_users_root

6. crc_dict_deliv_type_root

7. crc_dict_delivery_type

8. crc_dict_dockind_names_root

9. crc_dict_dockind

10. crc_dict_dockind_name

11. crc_dict_relations_root

12. crc_dict_relation

13. crc_dict_urgent_param_root

14. crc_dict_urgent_param

15. crc_dict_confer_type_root

16. crc_dict_conference_type

17. crc_dict_object_root

18. croc_confidential_types

19. crc_dict_role_info

20. crc_dict_commissions_root

21. ga_corp_question_kind_root

22. ga_corp_question_kind

23. ga_attr_value_list

24. croc_policies_types

25. crc_dockind_group

26. croc_corporate_root

27. croc_card_config

28. ga_attachment_kind_root

29. crc_dict_inbox_doctype

30. crc_dict_case_spec_root

31. crc_dict_cases_root

32. crc_dict_case_type_root

33. crc_dict_corrgroups_root

34. crc_dict_emplgroups_root

35. crc_dict_arch_heading_root

36. crc_dict_delivery_subtype

37. crc_dict_chief_user_root

38. croc_attachment_types

39. crc_dict_deal_kind_root

40. crc_dict_mailinggroups_root

41. crc_dict_addressees

42. ga_hpsm_routing_table_root

43. mr_template

В качестве источника выгрузки справочников был использован репозиторий Documentum

продуктивной системы ЕОСДО.

76

В ходе выгрузки утилита последовательно отбирает перечисленные объекты, создает

java-бины для этих объектов и сохраняет их в базовом java-объекте WasabiObjects. Дальнейшая

обработка зависит от приемника.

В качестве приемника выгрузки был использован формат сериализованного в файл

объекта WasabiObjects.

При загрузке в инсталляцию системы используется обратная конфигурация – источником

служит файл с сериализованным объектом WasabiObjects, приемником – целевой репозиторий

системы. Утилита выполняет операции создания и обновления объектов, но не выполняет

операции удаления объектов (в том числе, не удаляет атрибуты, если они уже были созданы в

целевом репозитории, но их нет в источнике). При загрузке каждого объекта производится поиск

ранее загруженного объекта в целевом репозитории по ключевому полю. В случае если объект не

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

6 ПЕРЕНОС ЭЛЕМЕНТОВ СТРУКТУРЫ БАЗЫ ДАННЫХ

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

элементы структуры базы данных из существующей системы (в указанном порядке):

1. Типы (type)

2. Таблицы (table)

3. Пакеты (package)

4. Функции (function)

5. Представления (view)

6. Последовательности (sequence)

7. Триггеры (trigger)

8. Журналы материализованных представлений (materialized view log)

9. Материализованные представления (materialized view)

10. Процедуры (procedure)

11. Индексы (index)

12. Джобы (user_scheduler_jobs)

В рамках данного проекта для переноса структуры базы данных использовались скрипты

DDL, сформированные с помощью инструмента SQLDeveloper. Во всех сформированных

скриптах DDL нужно заменить схему на ROSATOM (или удалить ее).

При формировании скриптов для создания таблиц и представлений необходимо

исключить стандартные объекты базы данных и объекты, автоматически созданные Documentum

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

77

select dbms_metadata.get_ddl(object_type, object_name, owner)

from

(

select

owner,

object_name,

decode(object_type,

'DATABASE LINK', 'DB_LINK',

'JOB', 'PROCOBJ',

'RULE SET', 'PROCOBJ',

'RULE', 'PROCOBJ',

'EVALUATION CONTEXT', 'PROCOBJ',

'CREDENTIAL', 'PROCOBJ',

'CHAIN', 'PROCOBJ',

'PROGRAM', 'PROCOBJ',

'PACKAGE', 'PACKAGE_SPEC',

'PACKAGE BODY', 'PACKAGE_BODY',

'TYPE', 'TYPE_SPEC',

'TYPE BODY', 'TYPE_BODY',

'MATERIALIZED VIEW', 'MATERIALIZED_VIEW',

'QUEUE', 'AQ_QUEUE',

'JAVA CLASS', 'JAVA_CLASS',

'JAVA TYPE', 'JAVA_TYPE',

'JAVA SOURCE', 'JAVA_SOURCE',

'JAVA RESOURCE', 'JAVA_RESOURCE',

'XML SCHEMA', 'XMLSCHEMA',

object_type

) object_type

from dba_objects

where owner in ('ROSATOM')

and object_type in ('TABLE')

and object_name not like '%_S' and object_name not like '%_R'

and object_name not like 'SYS_EXPORT_SCHEMA%'

and object_name not like 'MLOG$_%' and object_name not like 'dm_%'

and object_name not like 'dmi_%'

and object_name not in ('DUAL', 'SQLN_EXPLAIN_PLAN', 'TOAD_PLAN_TABLE',

'DMI_OBJECT_TYPE')

and (owner, object_name) not in (select owner, table_name from

dba_nested_tables)

and (owner, object_name) not in (select owner, table_name from dba_tables

where iot_type = 'IOT_OVERFLOW')

)

order by object_name;

Для формирования DDL по представлениям был использован запрос:

78

select dbms_metadata.get_ddl(object_type, object_name, owner)

from

(

select

owner,

object_name,

decode(object_type,

'DATABASE LINK', 'DB_LINK',

'JOB', 'PROCOBJ',

'RULE SET', 'PROCOBJ',

'RULE', 'PROCOBJ',

'EVALUATION CONTEXT', 'PROCOBJ',

'CREDENTIAL', 'PROCOBJ',

'CHAIN', 'PROCOBJ',

'PROGRAM', 'PROCOBJ',

'PACKAGE', 'PACKAGE_SPEC',

'PACKAGE BODY', 'PACKAGE_BODY',

'TYPE', 'TYPE_SPEC',

'TYPE BODY', 'TYPE_BODY',

'MATERIALIZED VIEW', 'MATERIALIZED_VIEW',

'QUEUE', 'AQ_QUEUE',

'JAVA CLASS', 'JAVA_CLASS',

'JAVA TYPE', 'JAVA_TYPE',

'JAVA SOURCE', 'JAVA_SOURCE',

'JAVA RESOURCE', 'JAVA_RESOURCE',

'XML SCHEMA', 'XMLSCHEMA',

object_type

) object_type

from dba_objects

where owner in ('ROSATOM')

and object_type in ('VIEW')

and object_name not like '%_SP' and object_name not like '%_RP'

and object_name not like '%_SV' and object_name not like '%_RV'

and not (object_type = 'TYPE' and object_name like 'SYS_PLSQL_%')


dba_nested_tables)


dba_tables where iot_type = 'IOT_OVERFLOW')

)

order by object_name;

После установки всех объектов в базу, нужно скомпилировать инвалидные объекты.

На окружениях системы присутствует конфигурация с архивной СУБД, данные в

которую передаются через Archive Link. Перенос данных из сконфигурированной СУБД в

архивную осуществляется штатными средствами Oracle, чтобы избежать необходимости

повторных операций.

79

2 7. НАСТРОЙКА РЕПОЗИТОРИЯ DOCUMENTUM

Для функционирования новой инсталляции системы необходимо выполнить скрипты для

разрешения работы с динамической группой dm_superusers_dynamic.

DQL: update dm_group object set is_protected=0 where

group_name='dm_superusers_dynamic'

API: retrieve,c,dm_group where group_name='dm_superusers_dynamic'

append,c,l,groups_names

dm_world

save,c,l

8. СОЗДАНИЕ СИСТЕМНЫХ НАСТРОЕК ЕОСДО

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

системных настроек ga_system_settings. В частности настройки cma, DeleteInformations, jdbs,

shark, smtp, Для создания настроек используется DQL-скрипт, адаптируемый для каждой целевой

площадки.

9. ДОБАВЛЕНИЕ КОНФИГУРАЦИИ ДЛЯ ЛАНДШАФТА СИСТЕМЫ В КОД

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

артефактов для новых площадок

80

VII ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ

Лист регистрации изменений

Из

м.

Номера листов (страниц) Всего

листов

(стра-

ниц) в

докум.

№

документа

Входящий

№ сопро-

водительного

докум. и

дата

Под

п.

Да

та

изме-

ненны

х

заме-

ненн

ых

новы

х

анну-

лиро-

ванных