Партнерка на США и Канаду по недвижимости, выплаты в крипто
- 30% recurring commission
- Выплаты в USDT
- Вывод каждую неделю
- Комиссия до 5 лет за каждого referral
Все ОФК вероятнее всего будут offline. Все документы на в ОФК offline должны заполняться вручную (для этого верно должны настраиваться Системные константы вследствие чего будет отсутствовать возможность заполнения из справочников, в связи с возможностью их неактуальности из-за отсутствия online подключения). Все АРМ которые являются оперзалом автоматически являются offline комплексом.
Для настройки сервера как OFFLINE/ ONLINE необходимо на панели навигации, перейти по следующему пути: «Настройки криптографии» -> «Транспортные настройки» (см. рисунок).
Указать тип комплекса: «Онлайн» или «Офлайн».
При выборе «Офлайн» комплекса, необходимо из списка выбрать организацию «Онлайн» - комплекса (на котором ЭЦП будет дополняться до УЭЦП) и организацию «Онлайн» - комплекса (запрос САС).
Настройка автопроцедур
Настройка автопроцедур осуществляется через АРМ «Администратор системы» или в разделе «Администрирования» в Тонком клиенте.
Создание новой автопроцедуры:
Для создания новой автопроцедуры необходимо выполнить следующую последовательность действий:
1. На панели навигации, перейти по следующему пути: «Администрирование комплекса» -> «Автопроцедуры» (см. рисунок).
2. На панели инструментов нажать кнопку «Добавить задание».
3. Далее необходимо перейти на закладку «Исполняемая операция (3)» и нажать кнопку 
. В появившемся окне сначала заполняется поле «Наименование» (см. рисунок). Значение поля выбирается из выпадающего списка.
4. В случае, если для выбранной операции необходимо изменить ее аргументы, нужно сделать следующее:
- активировать опцию «Переопределить», поставив галочку в соответствующем поле;
- выполнить двойной щелчок правой клавишей мыши на изменяемом значении;
- отредактировать значение параметра;
- по окончании редактирования параметра обязательно нажать клавишу ENTER.
5. После задания всех параметров создаваемой операции, нужно нажать кнопку «Сохранить».
Примечание. В случае если «Аргументы операций» редактируются в первый раз, то их значения, установленные по умолчанию, в момент их переопределения будут сброшены. Что бы избежать возможных ошибок при задании новых значений с нуля, можно сделать следующее:
- Добавить операцию, сохранить ее без изменений.
- Перейти на закладку «Общие(1)» и в окне «Совокупный результат настроек» скопировать аргументы операции действующие по умолчанию.
- Затем вернуться на закладку «Исполняемые операции» и изменить значение на скопированное нами ранее с внесенными изменениями. Если параметр может принимать несколько значений, то они разделяются между собой строго точкой с запятой (;) без пробелов.
6. Для окончания создания автопроцедуры переходим на закладку «Общие (1)», заполняем название автопроцедуры (обычно копированием названия исполняемой операции с закладки «Исполняемая операция (3)»), указывается имя сервера (чаще всего, localhost), устанавливаются дополнительные параметры и сохраняется АП по кнопке «Сохранить задание».
Внимание! Важным условием на закладке «Общие (1)» является галочка, проставленная в поле «Ожидание повторного запуска», при установке которой несколько одинаковых автопроцедур не будут запускаться одновременно, а будут ставиться в очередь друг за другом и ожидать завершения выполнения предыдущего задания в очереди. Если на какое-то время необходимо запретить выполнение АП, то это можно сделать при помощи галочки «Запретить АП». Также можно задать, чтобы АП исполнилась при старте или при остановке сервера приложений.
Работа с планировщиком и условиями запуска
Календарный запуск
Для настройки условий и ограничений запуск автопроцедуры необходимо выполнить следующую последовательность действий:
1. Выбрать из списка нужную автопроцедуру и нажать кнопку «Редактировать».
2. Перейти на закладку «Условия и ограничения запуска (2)» и нажать кнопку «Добавить условие». В появившемся окне в поле «Наименование» нужно указать название условия. Название выбирается из выпадающего списка или задать самостоятельно (см. рисунок).
3. В случае, если создается новое условие запуска, сначала снимается галочка в поле «Из списка». Затем в поле «Наименование» вводится название условия и редактируется расписание его запуска. Если условие будет использоваться для нескольких автопроцедур, то нужно поставить галочку в поле «Типовое». Если настраивается не условие, а ограничение запуска, необходимо проставить галочку «Ограничение запуска».
4. Для сохранения созданного условия нажать кнопку «Сохранить».
В данном расписании установлено, что Задание будет запускаться в декабре, январе и феврале во все числа месяца, если эти числа не приходятся на воскресенье. Запуск будет производиться в 20-00, если число приходится на дни недели Пн.-Пт., в 18-00, если число приходится на Сб.
Примечание. Ограничение запуска используется для установки запрета на запуск автопроцедуры при выполнении определенных условий. Например, если условие запуска настроено на ежеминутный старт автопроцедуры, а нам необходимо сделать так, чтобы по понедельникам с двух до четырех часов ночи, автопроцедура не запускалась. Задачу можно решить двумя способами: отредактировать существующее условие запуска или добавить новое ограничение запуска, в котором указать дни и часы, по которым задание запускаться не будет.
Запуск постзаданий
Когда необходимо, чтобы задания запускались друг за другом, используется условие запуска «Постзадание». Для использования этого условия надо выполнить следующую последовательность действий:
1. Выбрать из списка нужную автопроцедуру и нажать кнопку «Редактировать».
2. Перейти на закладку «Условия и ограничения запуска (2)» и нажать кнопку 
,расположенную справа от кнопки «Добавить условие» (см. рисунок)..В появившемся списке активировать радиокнопку «Постзадание» и после этого нажать кнопку «Добавить условие»
3. Параметры условия запуска для постзадания задаются аналогично тому, как это делается при создании условия запуска для обычного задания. Только дополнительно в поле «Постзадание» необходимо указать задание, после которого будет запускаться текщее (см. рисунок).
4. Для сохранения созданного условия нажать кнопку «Сохранить».
Также часто используется RMI-вызов на событие БД. Данный вид условия запуска подробно рассмотрен в разделе «Автопроцедуры для ЭЦП».
Полный перечень доступных автопроцедур представлен в разделе «Приложение 5. Перечень используемых автопроцедур»
Работа с печатными формами
Для возможности печати документов в внешних приложениях (MS Word, Excel, Acrobat Reader и т. д.), а также для возможности передачи отчетов из OeBS в СЭД, необходимо наличие в системе Печатных форм.
Для работы механизма печати необходимо наличие в системе заполненных справочников:
- Служебный словарь Связи шаблонов и отчетов. Содержит привязку шаблонов к типам документов.
- Служебный словарь Версий шаблонов отчетов. Содержит печатные формы шаблонов в различных форматах.
- Служебный словарь Шаблонов отчетов. Содержит общее описание шаблона: Выводимое наименование, системное название шаблона, тип шаблона по умолчанию (RTF, DOC, PDF, TFF и т. д.).
Служебный словарь Связи шаблонов и отчетов выгружается из OeBS (см. раздел «Выгрузка справочников из BackOffice (OeBS)») и далее распространяется при помощи механизма репликаций (см. разделы «Настройка репликаций», «Репликация справочников»). В OeBS данный справочник называется «АСФК: Ассоциатор мгновенных отчетов».
Служебный словарь Версий шаблонов отчетов и Служебный словарь Шаблонов отчетов заполняются при помощи распаковки и обработки «Сервисного документа доставки шаблона отчета» при помощи «Автопроцедуры заполнения справочника печати», далее этот сервисный документ отправляется на дочерние комплексы при помощи рассылки (АП Рассылки документов), также, для подстраховки, на дочерние комплексы отправляются и словари при помощи механизма репликаций.
Для выгрузки Сервисного документа необходимо зайти в OeBS в раздел «Настройка шаблонов отчетов». Найти необходмый шаблон (по имени шаблона, которое можно получить из справочника «Служебный словарь Связи шаблонов и отчетов»), выбрать его в списке, нажать кнопку «Выполнить». В появившемся окне выбрать «Выгрузка метаданных». Далее по механизму взаимодействия с BackOffice (OeBS) сервисный документ будет доставлен до СУФД.
Также для выгрузки отчетов из OeBS в СЭД необходимо иметь заполненный справочник «Соответствие типов и статусов документов». Для его заполнения необходимо выгрузить справочник «ФК: Соответствие типов и статусов документов АСФК и ТФФ» см. раздел «Выгрузка справочников из BackOffice (OeBS)».
Работа транспорта
Общее описание
Документ после его отправки в транспорт упаковывается (сериализуется) и помещается внутрь транспортного документа, который сохраняется в базу.
Есть несколько сервисов:
1. пакетирование документов. Берет исходящие документы, делает из них пакеты, которые помещает в исходящую очередь пакетов
2. Отправка исходящих пакетов. Берет исходящий пакет и кидает на ФТП/ФС или по HTTP
3. Прием входящих пакетов. Берет входящие пакеты (из QUEUE_PACKET_IN, куда их кладет mule, забирая с FTP, HTTP или файловой системы), «распаковывает» и получает из них транспортный документ, который сохраняет в базу
4. Прием входящих документов. Берется входящий транспортный документ, из него достается документ/ЖИД и сохраняется/накатывается
Каждое из этих заданий запускается по своему расписания (в порядке перечисления (documentQueue. send, packetQueue. send, packetQueue. unpack, documentQueue. store). В настоящий момент возможны два режима работы сервисов обработки очередей:
а) при каждом срабатывание сервиса (по таймеру) сервис лезет в базу, достает оттуда порцию пакетов и обрабатывает всю порцию
б) при каждом срабатывании сервиса он обращается к другому сервису, который хранит в себе множество загруженных пакетов. Этот сервис отдает каждому сервису обработки по одному пакету/документу. Если у сервиса кончаются документы/пакеты он подтягивает очередную порцию из базы.
Вариант б) предполагался как замена а), но пока решили оставить оба. Основное отличие второго способа в том, что он минимизирует количество обращений к базе и упрощает запросы (исключает из них дополнительные условия). Однако, он имеет смысл при большом объеме транспортной очереди, достаточно частом срабатывании сервисов и большом размере порции загрузки.
Переключение режимов работы осущствляется параметрами documentQueue. inMemoryQueue (для документарной очереди, true включает вариант б)) и packetQueue. inMemoryQueue (для очереди пакетов).
Каждый из четырех сервисов может запускаться одновременно несколько раз. При этом каждый из сервисов будет обрабатывать свою порцию документов/пакетов. Это определяется:
а) частотой срабатывания этих сервисов (парамерты я перечислял выше)
б) размером пула поток для сервисов очередей (transportThreadPool. maxPoolSize)
в) и количеством паралельно работающих сервисов одного типа (определяется параметрами из группы transportThreadPool. threadlimits)
Кроме того, при использовании inMemoryQueue возможно использование механизм замедления опроса БД (начиная с 5.2.3), который работает следующим образом:
1. Если сервис выборки пакетов/документов на обработку не выбрал ничего из БД за documentQueue. delay. startdelaycount раз, то включается механизм замедления
2. При первом запуске в режиме замедления берется значение параметра documentQueue. delay. mindelay, и в течение этого времени (в секундах) сервис не будет обращатся к БД
3. При последующих запусках вычисляется новое время задержки, к documentQueue. delay. mindelay прибавляется documentQueue. delay. mindelay*documentQueue. delay. delayfactor. Таким образом с каждым разом, пока сервис ничего не находит в базе, он будет обращаться к БД все медленнее и медленее, вплоть до задержки величиной в documentQueue. delay. maxdelay (секунд). Таким образом, в дефолтной конфигурации, если в транспортных очередях нет никаких данных, то СУФД будет обращаться к ним не каждые 2 секунды, а раз в минуту
4. Как только сервису удается выбрать что-то из базы (появились новые пакеты или документы), сбрасываются все счетчики и задержки. Далее начиная с пункта 1.
Аналогичный механизм реализован в backoffice-е.
Параметр singleFileStrategy включается использование единого временного файла для хранения данных при отправке пакетов/упаковке транспортных документов. Если эта настройка выключена, то при создании пакета/транспортного документ создается один временный файл на каждый пакет/документ. Если настройка включена, то создается только один временный файл в который поочередно пишутся временные данные всех пакетов/документов. Это способ может позволить:
а) решить проблему Too many open files
б) увеличить скорость работы транспорта при обработке очень большого количества маленьких пакетов/документов.
Описание транспорта на уровне БД
В структуре хранения транспортных сущностей произошли большие изменения. На текущий момент не используются таблицы, которые писпользовались ранее, например: T_DOCUMENT_QUEUE, T_SHIPMENT_QUEUE, T_SHIPMENT_ITEM, T_DOCLOG. Перенос данных из старых таблиц не возможен.
Краткое описание таблиц ниже:
Таблица QUEUE_DOCUMENT
Таблица содержит в себе входящие/исходящие транспортные документы. То же самое, что T_DOCUMENT_QUEUE
Колонка | Описание |
GUID | Гуид транспортного документа |
CHANGE_STATUS_DATE | Дата последней смены статус транспортного документа |
CONTENTOBJECTGUID | Гуид объекта, содержащегося в транспортном документа |
URGENCY_LEVEL | Признак срочности (вроде так и не используется) |
RESEND_COUNT | Количество произошедших повторных отправок |
QUEUE_ITEM | Блоб с содержимым транспортного документа |
CONTENTCLASSNAME | Имя класса объекта, хранящегося внутри транспортного документа. Пока это com. fd. oapi. edit. Document и com. fd. core. doclog. DocLogRecord |
CREATE_ORG_SYS_NAME | Организация создатель транспортного документа |
ITEM_STATUS | Статус транспортного документа см ниже |
CREATION_DATE | Дата создания записи в таблице |
DIRECTION | Направление транспортного документа IN (входящий)/OUT (исходящий) |
ERROR_MESSAGE | Последнее сообщение об ошибке (если было) |
Порядок статусов транспортного документа:
· Отправка. SEND_READY (создан) — SENT (отправлен)/SENDING_ERROR(ошибка отправки)/PACKAGING_ERROR (ошибка упаковки в пакеты)
· Прием. RECEIVED (принят) - PROCESSING_ERROR(ошибка) / PROCESSED (обработан) / RECIPIENT_ERROR (ошибка обработки для ЖИДов)
Общие статусы:
· ARCHIVE (документ отправлен/принят, пришли квитанции)
· RESEND_LIMIT_EXHAUSTED (документ не был отправлен в ходе N отправок)
Таблица QUEUE_PACKET_IN
Предназначена для хранения входящих в СУФД пакетов (*.shipment, *.revising + ТФФки). Аналог T_SHIPMENT_ITEM, т. е. в ней хранятся непосредственно пакеты.
Колонка | Описание |
ID | Ид пакета |
FILENAME | Имя файла из которого был загружен пакет |
RECEIVEDATE | Дата получения |
SEQGUID | Гуид последовательности (для *.shipment) |
SEQNUM | Номер пакета в последовательности |
SEQSIZE | Общий размер последовательности |
FILE_SIZE | Размер исходного файла |
BLOBCONTENT | Содержимое файла |
ERRORMESSAGE | Последняя ошибка (если есть) |
STATUS | Статус (см ниже) |
COMPLEXTYPE | Тип комплекса куда идет пакет. SUFD/SED |
PARENT_ID | Ид родительского пакета (для случая когда этот пакет был распакован из «мета-пакета» |
EXPORTED | Признак того, что пакет был выгружен на ФС в папки bad/good |
Порядок следования статусов для входящих пакетов
· RECEIVED (получен) — ARCHIVE (обработан)/ERROR (ошибка обработки)
Таблица QUEUE_PACKET_OUT
Предназначена для хранения ияходящих пакетов (*.shipment, ТФФки). Аналог T_SHIPMENT_ITEM, т. е. в ней хранятся непосредственно пакеты.
Колонка | Описание |
ID | Ид пакета |
URL | Имя файла из которого был загружен пакет |
CREATEDATE | Дата создания |
SEQGUID | Гуид последовательности (для *.shipment) |
SEQNUM | Номер пакета в последовательности |
SEQUENCESIZE | Общий размер последовательности |
FILE_SIZE | Размер файла |
BLOBCONTENT | Содержимое файла |
ERRORMESSAGE | Последняя ошибка (если есть) |
STATUS | Статус (см ниже) |
CONTENTCLASSNAME | Имя класса содержимого com. fd. transport. domain. shipment. Shipment (пакет), com. fd. transport. domain. shipment. Revising (квитанция или TFF File (ТФФка) |
Порядок следования статусов для исходящих пакетов:
· SEND_READY(готов к отправке) — SENDED (отправлен)/ERROR (ошибка отправки) — ARCHIVE (архивный. На пакет получена квитанция - revising)
Так же есть две таблицы, которыя связывают исходящие и входящие пакеты с транспортными документами
· QUEUE_IN_PACK2DOCQ (привязка QUEUE_PACKET_IN к транспортному документу)
· QUEUE_OUT_PACK2DOCQ (привязка QUEUE_PACKET_OUT к транспортному докменту)
Таблица DOCUMENT_QUEUE_TO_ORG определяет организации-получатели для транспортного документа (может быть больше 1).
Настройка Контролей документов
Для настройки контролей на документы необходимо зайти в СУФД в раздел «Администрирование – Администрирование комплекса – услуги». Найти необходимый документ в дереве документов, для более удобного поиска можно воспользоваться сочетанием клавиш CTRL+F (актуально для толстого клиента) ввести необходимо имя документа в точности с учетом регистра. Поиск осуществляется в открытых разделах
Далее нажать кнопку «Проверки документов», и откроется окно настройки проверок конкретного документа. В данном разделе приводится перечень доступных проверок документа. Каждой проверке можно определить критерий использования проверки (использовать или нет) и уровень (предупреждающий контроль или блокирующая ошибка)
Для включения/выключения использования и для определения уровня проверки необходимо нажать на кнопку «Редактировать исключение».
Интеграция СУФД с Сервером Безопасности
Партнёрская система
Запускаем СБ и АРМ «Администратор безопасности». Указываем имя пользователя и пароль (по умолчанию)
admin amover
pupkin tenoza
mike zomavi
ic cusofu
otr_user qwerty
После этого необходимо выбрать раздел «Партнерские системы» и создать новую партнерскую систему для СУФД.
В настройках партнёрской системы СУФД необходимо прописать:
Наименование и Код – произвольно, код – латинскими буквами
строка соединения с базой данных СУФД -
jdbc:oracle:thin:@//172.17.1.130:1521/OFK4806
172.17.1.130 – имя сервера или ip сервера, на котором запушен листенер базы данных СУФД
1521 – порт процесса прослушивания
OFK4806 – SID базы данных СУФД
Тип партнерской системы - SUFD
После заполнения настроек необходимо сохранить партнерскую систему.
Установка SSO-proxy-server-а.
Копируем папку sso-proxy-server-sufd в указанную директорию.
Все конфигурационные файлы находятся в папке sso-proxy-server-sufd\conf\.
Внимание! При настройке sso используется доменное имя ПК, на котором устанавливается sso и которое должно быть прописано в WINDOWS\system32\drivers\etc\hosts в виде:
IP-адрес <доменное имя машины>
IP-адрес sufd.<доменное имя машины>
Для машин, не включенных в локальную сеть (СУФД ОФК-оффлайн ЗК), с операционной системой семейства Windows , не имеющей dns-сервера), необходимо также к имени машины (ПК) дописать dns-суффикс.
Мой компьютер – Свойства - Имя компьютера – Изменить – Дополнительно
в окне DNS-суффикс и NetBios – имя компьютера написать dns-суффикс
например: otr. ru
В файле sso-proxy-server-sufd\conf\server. xml указываем порт proxy-сервера в строке
Server port="8005"
и параметры для соединения с http сервером, на котором разворачивается sso.
Определяем порт и хост (как доменное имя; в качестве примера используется имя машины – h2.ru. ):
<Connector port="48006" protocol="HTTP/1.1" connectionTimeout="20000" />
<Engine name="Catalina" defaultHost="sufd. h2.ru. ">
В файле sso-proxy-server-sufd\conf\ssoproxy-config. xml указываем порт и хост сервера СБ:
<!--
Строка коннекции к СБ
--> f(clean);
<element descriptor-name="security-server-connection">tcp:// h2.ru. :3000</element>
Далее настраиваем кэш для СБ.
Настройки кэша для СБ находятся в файле conf/ehcache. xml. По умолчанию, он выглядит таким образом:
<cache name="metadata"
maxElementsInMemory="30000"
maxElementsOnDisk="0"
eternal="false"
overflowToDisk="false"
diskSpoolBufferSizeMB="100"
timeToIdleSeconds="300"
timeToLiveSeconds="3600"
memoryStoreEvictionPolicy="LRU"
/>
Для большей производительности необходимо увеличивать параметр maxElementsInMemory. Для более быстрого доступа рекомендуется:
maxElementsInMemory="300000".
Для получения статуса кэша необходимо в консоли с запущенным СБ выполнить команду stat:
Cache statistics:
Ehcache[ name = metadata cacheHits = 0 onDiskHits = 0 inMemoryHits = 0 misses = 0 size = 0 averageGetTime = 0.0 evictionCount = 0 ] Objects in memory : 0 Objects in disk store : 0
Необходимо обращать внимание на параметры misses = 0 evictionCount = 0, если все работает медленно, а данные значения все время растут, то необходимо увеличить параметр maxElementsInMemory. Так же можно попробовать установить параметры overflowToDisk="true" и maxElementsOnDisk="1000000". При быстрой дисковой подсистеме это так же даст прирост производительности.
Внимание! Данные опции могут замедлить работы, тогда необходимо вернуть значения обратно!
В файле sso-proxy-server-sufd\conf\ssoproxy-login-config. xml
в строке:
<!--
Корневой сервер прокси (для выставления кук сессии)
--> f(clean);
<element descriptor-name="rootServer"> h2.ru. </element>
- указываем корневой сервер прокси.
в строке:
<!--
Основа всех URL, относящихся к аутентификации sso-proxy
--> f(clean);
<element descriptor-name="loginBaseURL">http:// h2.ru. :48006/sso-proxy-login/</element>
- указываем порт и корневой домен прокси
в строке:
<!--
Целевой URL в случае успешной аутентификации
--> f(clean);
<element descriptor-name="successLoginURL">http://sufd. h2.ru. :48006/docapp-3/app. jnlp</element>
- указываем URL, на который идет переадресация при успешной аутентификации.
В файле sso-proxy-server-sufd\conf\ssoproxy-proxy-config. xml в строках
<!--
Сервер обработки запросов плагина (вирт. хост плагина)
--> f(clean);
<element descriptor-name="serverName">sufd. h2.ru. </element>
- <!--
host сервера приложений
--> f(clean);
<element descriptor-name="targetHost"> h2.ru. </element>
- <!--
port сервера приложений
--> f(clean);
<element descriptor-name="targetPort">18080</element>
- указываем хост и порт сервера СУФД.
В данном примере - STAND СУФД и ssoproxy-proxy расположены на одном хосту – h2.ru.
Сопровождение СУФД
Настройка уровня логирования.
В системе СУФД предусмотрено логирование серверной части (находится по пути STAND\logs\server. log) и пользовательской(application. log) который по умолчанию находится на рабочем столе пользователя.
Для настройки пользовательского лога для отображения в реальном времени, т. е в консоли, необходимо зайти в «Панель управления» - «java» - «Advanced» - «java console»- «show». После этого запустить приложение.
Для настройки серверного лога необходимо зайти в STAND\etc\log4j. properties
Пример:
log4j. appender. console=org. apache. log4j. ConsoleAppender
log4j. appender. console. layout=org. apache. log4j. PatternLayout
log4j. appender. console. layout. ConversionPattern=%d %-5p [%c] %m%n
log4j. appender. console. Threshold=ERROR - максимальный уровень логирования в консоли
log4j. appender. file=org. apache. log4j. RollingFileAppender
log4j. appender. file. file=logs/server. log - лог сервера, относительный путь по которому он лежит
log4j. appender. file. Threshold=TRACE – максимальный уровень логирования при записи в файл
log4j. appender. file. layout=org. apache. log4j. PatternLayout
log4j. appender. file. layout. ConversionPattern=%d %-5p [%c] %m%n
log4j. appender. file. MaxFileSize=100MB- 100MB –размер лога максимальный. В случае если лог будет превышать данный размер, старый лог сохраняется в файл с номером лога, например server. log.1 по тому же пути, и лог пишется с чистой страницы.
log4j. appender. file. MaxBackupIndex=3"/>- количество максимально хранимых логов превысивших максимальное значение
В тегах вида:
log4j. logger…. =…
устанавливается уровень логирования
Допустимые варианты значений – начиная от самого детализированного к наименьшему: TRACE, DEBUG, INFO, WARN, ERROR, FATAL
В файле log4j. rootCategory=DEBUG, console, file - общие настройки логирования. В случае если в нем будет стоять уровень логирования ERROR, настройки конкретного класса выводиться будут не больше установленного данного уровня, в не зависимости от уровня логирования на конкретном классе.
Изменения уровня логирования можно производить не перезапуская сервер стенда. Изменения вступят в силу не позднее 1-3 минут низменных параметров логирования. Если, например, лог по умолчанию стоит в уровне логирования файла ERROR(т. е запись только ошибок), и необходимо перевести его в DEBUG(детальный уровень логирования) в этом случае делаются изменения в log4j. appender. file. Threshold=TRACE(можно оставить TRACE, в виду его больше детализированности, а следовательно он в себя включает DEBUG), log4j. rootCategory=DEBUGE, console, file
log4j. . fd=DEBUG
таким образом будет идти логирование детализированное основных функций(классов) СУФД.
В случае если необходимо выходит ошибка, например подобного вид:
ERROR [org. mule. DefaultExceptionStrategy] Caught exception in Exception Strategy: java. io. NotSerializableException:…
В данном случае может понадобится более детальный лог класса org. mule. DefaultExceptionStrategy, для этого необходимо изменить уровень логирования еще и в log4j. logger. org. mule=DEBUG. Ключевыми фразами для поиска необходимого логгера служит схожесть наименований в классе на котором вышла ошибка и в наименовании логе. В данном случае это org. mule.
Настройки производительности
1.Большую роль на производительность играет Уровень логирования описанный выше. Для постоянной стабильной работы сервера рекомендуется ставить везде уровень логирования не выше ERROR. Т. е или ERROR – вывод всех ошибок в том числе блокирующие ошибки, или только уровень FATAL - блокирующие ошибки. Повышать уровень в случае необходимости, после чего возвращать его снова в минимальное состояние.
2. Настройки, которые они можно изменить на минимальные(как указано ниже) для улучшения производительности в файле etc/sufd. properties(описание настроек см. пункт «Настройка конфигурационных файлов сервера»):
sufd. hibernate. show_sql=false
sufd. hibernate. format_sql=false
Там же стоит выставить значения:
client. log4j. console. threshold=ERROR
client. log4j. file. threshold=ERROR
Но, если понадобится снять лог с клиента, то придется вернуть значение в DEBUG, и перезапустить стенд.
3.Не малую роль играет так же работа транспорта. А менее мощных машинах или с конфигурацией ниже требуемой для СУФД, необходимо корректно выбирать интервалы обработки пакетов(см. пункт «Настройка комплексов, транспортных адресов и транспортных подключений.» Общие настройки). Если вам нужна работа транспорта приближенная к реальному времени (отправили документ из ДТВ и он сразу ушел по транспорту) то эти таймауты должны быть в пределах 5 сек. Если транспорт у вас отправляет пакеты лишь периодически – поднимайте значение до приемлемого уровня.
4.На машинах с минимальным количеством RAM советуется изменить настройки использовании ее в СУФД. Для этого в файлах \STAND\jetty. bat или jetty. sh в зависимости от используемой системы ОС изменить параметры:
Для HP-UX:
GC_SETTINGS="-Xmx1500m - Xms512m -XX:MaxPermSize=512m - XX:+UseParallelGC - XX:+UseParallelOldGC"
Для Windows:
set GC_SETTINGS=-Xms512m - Xmx1024m -XX:PermSize=128m - XX:MaxPermSize=256m - XX:+AggressiveHeap - XX:+UseParallelGC
Где
- Xmx1500m - максимальный размер занимаемой СУФДом памяти
- Xms512m – минимальный размер занимаемой СУФДом памяти
MaxPermSize=512m - размер сборщика временных файлов
Установка патчей для схемы
Для установки патчей необходимо выполнить командный файл _sqlplusw.bat с параметрами ‘system/password_system’ из соответствующих каталогов патчей \<версия ядра, например 4.0.5.22-2008-02-06>\PATCH <переход с версии на версию, например 4.1.75.1-4.1.76.1>\ для обновляемой схемы данных. Где ‘system/password_system’ имя и пароль д. б(sid) обновляемой схемы.
Смена версии ядра
Когда происходит смена версии ядра, необходимо выполнить скрипт из<номер новой версии ядра СУФД>\Alters\ выполнить все скрипты любым доступным способом (через Toad, SQLPLUS, …или др).
Обновление стенда
Необходимо установить все патчи для соответствующей версии приложения (определить версию прикладного приложения однозначно нельзя, поэтому необходимо всегда помнить версию приложения. Приблизительную версию можно просмотреть в файле STAND\version. txt, а так же в таблице схемы данных данного обновляемого стенда VERSIONS).
Обновление прикладной части выполняется простым копированием с заменой существующих файлов из каталога <номер версии стенда>\Update\PATCH<номер версии>\
Внимание! После обновления версий СУФД желательно Отчистить кеш java, для этого необходимо зайти в «Панель управления» - «java» - Settings…» - «Delete Files…»- Затем выбрать все пункты – «OK» – «OK» – «OK».
Так же отчистить Internet Explorer jn временных файлов.
Управление паролями
По окончании инсталляции прикладной системы, требуется сменить пароли пользователей для безопасности, назначенные по умолчанию, или заблокировать их.
Внимание! Пароли пользователей БД меняются по мере необходимости.
Категорически запрещается передача паролей пользователей Oracle: SYS, SYSTEM, SYSMAN, DBSNMP.
Список пользователей и паролей, установленных в системе по умолчанию, отображены в таблицах ниже.
Пользователи Oracle
Пользователь | Пароль |
SYS | Задается во время создания БД |
SYSTEM | Задается во время создания БД |
SYSMAN | Задается во время создания БД |
DBSNMP | Задается во время создания БД |
Прикладные пользователи
Прикладная система | Пользователь | Пароль |
Сервер СУФД | Bear | Пустой |
СБ | admin | amover |
ТС | transport | a12345 |
Цензор | censor | auditor |
Возможные проблемы и пути их решения
Проблема.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 |
Проекты по теме:
Основные порталы (построено редакторами)