| WEB-приложение Сведение отчетности- Часто задаваемые вопросы (раздел целиком) (26.07.2026) | (одним файлом) |
Часто задаваемые вопросы |
1. Получение SSL-сертификата |
1.1. Протокол SSL |
SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) SSL это криптографический протокол использующий протокол TCP/IP, т.е. он (SSL) находится между транспортным протоколом TCP/IP и протоколами прикладного уровня HTTP, SMTP, преобразуя их сообщения в шифрованный вид. Для работы по протоколу SSL требуется, чтобы на сервере был установлен SSL-сертификат. Безопасность соединения обеспечивается с помощью аутентификации (сертификат привязан к одному конкретному домену) и шифрования (передаваемая информация может быть расшифрована только с помощью специального ключа). Каждый сертификат содержит в себе информацию о:
SSL-cертификат подтверждает, что домен принадлежит реальной компании и что его владелец вправе пользоваться секретным ключом на законных основаниях. Выпуск SSL-сертификатов осуществляется Центрами сертификации. Существует большое количество Центров сертификации во всем мире, в том числе и в России. Однако, для того чтобы Ваш сертификат принимался во всем мире, желательно получить сертификат в большой международной организации. Наиболее известные мировые центры сертификации: В России интересы Центров сертификации представляют многие компании-регистраторы. Для примера далее рассматривается процесс получения SSL-сертификатов от Компании Thawte Products через российскую RU-CENTER. |
1.2. Виды сертификатов | ||||||||||||||||||||||||||||||||||||||||
Компания RU-CENTER предлагает получить SSL-сертификаты крупнейших международных Центров Сертификации. Для примера рассмотрен процесс получения сертификатов компании Thawte. Эта компания предлагает следующие виды SSL-сертификатов, наиболее востребованных в российских реалиях:
| ||||||||||||||||||||||||||||||||||||||||
1.3. Получение SSL-сертификатов |
Процедура получения SSL-сертификата для юридического лица состоит из двух этапов:
|
1.3.1. Предварительная подготовка |
Перед подачей заявления на выпуск SSL-сертификата необходимо выполнить следующие условия: |
1.3.1.1. Пакет документов | ||
|
1.3.1.2. Доменное имя | ||
Для того чтобы иметь возможность получить SSL-сертификат, ваше доменное имя должно быть зарегистрировано и иметь запись в международном сервисе WHOIS. Для того чтобы узнать наличие записи о Вашем доменном имени, перейдите по ссылке whois.
|
1.3.1.3. IP-адрес |
Для установки и корректного функционирования SSL-сертификата обязательно наличие выделенного IP-адреса. Если у вас несколько субдоменов на одном IP вы можете воспользоваться Wildcard SSL сертификатом. |
1.3.1.4. Адрес электронной почты | ||
По требованию Удостоверяющего центра при заказе SSL-сертификата необходимо указать адрес электронной почты (approver email), на который будет отправлен запрос на подтверждение выпуска сертификата. E-mail получателя может принимать одно из следующих значений:
где [имя_домена] должно соответствовать полю «Common Name» (CN), указанному в CSR. В случае если сертификат заказывается для поддомена, в e-mail допускается использовать домен второго уровня.
|
1.3.1.5. Создание аккаунта RU-CENTER | ||
Для заказа любого вида SSL-сертификата, например через компанию RU-CENTER, предварительно необходимо создать аккаунт на сайте RU-CENTER.
Заходим на страницу регистрации нового аккаунта .
|
1.3.1.5.1. Для физического лица | ||||||||||||||||||||||||||||||||
Заполнение анкеты:
После заполнения всех необходимых полей нажать кнопку "Отправить анкету" Будет выведено сообщение об успешном заполнении анкеты. На указанный почтовый ящик будет отправлено письмо с уведомлением об успешном заполнении анкеты. Для продолжения работы нажать кнопку "Начать работу". |
1.3.1.5.2. Для юридического лица | ||||||||||||||||||||||||||||||||||||
Заполнение анкеты:
После заполнения всех необходимых полей нажать кнопку "Отправить анкету" Будет выведено сообщение об успешном заполнении анкеты. На указанный почтовый ящик будет отправлено письмо с уведомлением об успешном заполнении анкеты. Для продолжения работы нажать кнопку "Начать работу". |
1.3.1.5.3. Для индивидуального предпринимателя (ИП) | ||||||||||||||||||||||||||||||||||||||||
Заполнение анкеты:
После заполнения всех необходимых полей нажать кнопку "Отправить анкету" Будет выведено сообщение об успешном заполнении анкеты. На указанный почтовый ящик будет отправлено письмо с уведомлением об успешном заполнении анкеты. Для продолжения работы нажать кнопку "Начать работу". |
1.3.1.6. Внесение денежных средств на личный счет |
Для того чтобы заказать SSL-сертификат через компанию RU-CENTER необходимо, чтобы перед отправкой запроса на личном счету в личном кабинете вашей компании было достаточно средств для оплаты данной услуги. Текущий баланс можно проверить в личном кабинете (Оплата - Баланс личного счета): Откроется страница внесения денежных средств: Здесь нужно ввести сумму в рублях, на которую Вы планируете пополнить баланс и нажать кнопку "Пополнить". После этого откроется страница выбора способа пополнения, на которой можно выбрать нужный вариант.
Рассмотрим процесс безналичного перевода:
|
1.3.2. Создание и отправка запроса |
1.3.2.1. Выбор типа сертификата |
Для заказа SSL-сертификата необходимо авторизоваться в личном кабинете на сайте nic.ru. Для этого в правом верхнем углу нажать "Вход" и в открывшейся странице ввести свои номер договора и пароль, полученные в процессе регистрации. При этом суффикс договора оставить "NIC-D". После ввода данных нажать кнопку "Вход" ниже. Откроется личный кабинет. В разделе "Заказать услугу" выбрать пункт "SSL-сертификат".  Откроется окно выбора типа сертификата:
Подробная информация о типах SSL-сертификатов: Виды сертификатовВыбрать необходимый сертификат и срок его действия, нажать "Продолжить". Откроется окно для ввода CSR-запроса. Подробно Создание CSR запроса |
1.3.2.2. Отправка CSR-запроса |
После того как Вы определились с видом желаемого сертификата, необходимо Создать CSR запрос и внести его в форму на странице: Заполнение поля запроса производится прямым копированием текста запроса из буфера обмена. После этого необходимо выбрать используемый Вами тип сервера из списка ниже. В случае если Вы планируете работу с Платформой "Мельница данных" - выберите пункт "Other" ("Другой"). Нажмите кнопку "Продолжить". На следующей странице:  некоторые из реквизитов будут заполнены автоматически на основании данных введенных Вами ранее при создании запроса и при регистрации аккаунта. Проверьте эти данные и заполните все остальные поля достоверной информацией. Все поля заполняются латинскими символами. Название организации в поле «Organization name» должно соответствовать данным указанным в CSR, в Whois домена и в свидетельстве о регистрации юридического лица. Длина названия организации не должна превышать 64 символов. В поля формы «Данные контактного лица» необходимо вводить корректную информацию, так как Удостоверяющий центр может воспользоваться ей для запроса дополнительных сведений. Нажмите кнопку "Продолжить" после заполнения всех полей. На следующей странице Вам будет предложено проверить все введенные данные. Если данные введены верно, нажмите кнопку "Отправить заказ". Данные будут отправлены. |
1.3.2.2.1. Создание CSR запроса | ||||||
Для генерации CSR-запроса существует несколько путей. Наиболее защищенным вариантом (рекомендуемым) является создание такого запроса с использованием OpenSource (свободно распространяемого) программного обеспечения OpenSSL Project (http://www.openssl.org/). На сайте проекта представлены открытые исходные коды программного обеспечения для обслуживания SSL-сертификатов. Коды находятся в свободном доступе на странице Исходные коды и могут быть скомпилированы под используемую конечным пользователем Платформу. Для Платформы Microsoft Windows готовые скомпилированные файлы проекта можно найти на сайте партнера проекта Shining Light Productions . В открывшемся списке файлов на этой странице выбрать вариант используемой операционной системы Windows компьютера, на котором будет производиться генерация CSR-запроса.
После нажатия на выбранную ссылку начнется процесс скачивания файла программного обеспечения (около 16 Мб). По завершении скачивания, необходимо запустить с локального диска файл Win32OpenSSL-1_0_0g(1).exe (для 32-хбитных систем) или Win64OpenSSL-1_0_0g(1).exe (для 64-хбитных систем). Процесс установки (на примере для 32-хбитных систем):
Предупреждение системы безопасности - нажать "RUN" ("Выполнить")
1-й экран установщика - нажать "Next" ("Далее")  Лицензионное соглашение - ознакомиться, выбрать пункт "I accept the agreement" и нажать "Next" ("Далее").  Выбор папки для установки - выбрать путь для установки программного обеспечения на жестком диске, нажать "Next" ("Далее").  Выбор папки установки в меню "Start" ("Пуск") - выбрать наименование папки, нажать "Next" ("Далее").  Выбор месторасположения дополнительных библиотек - установить библиотеки в папку установки программного обеспечения C:\OpenSSL\bin . Оставить без изменений, нажать "Next" ("Далее").  Проверка информации - проверить введенную ранее информацию, нажать "Install" ("Установить"). Начнется процесс установки программного обеспечения (около минуты). Далее появится окно:  Здесь разработчики предлагают внести посильный вклад в развитие проекта путем перечисления определенной суммы. Данное действие добровольное и, если Вы не хотите перечислять денежные средства разработчикам, просто уберите все галочки из этого окна и нажмите "Finish" ("Завершить"). Установка завершена. Для создания CSR-запроса необходима следующая последовательность действий:
На этом этап создания CSR-закончен. Можно переходить к следующему шагу Отправка CSR-запроса |
1.3.3. Дальнейшие действия | ||
После отправки запроса вам придет запрос от компании RU-CENTER на предоставление дополнительных документов с инструкцией. По запросу предоставьте все необходимые материалы, собранные ранее на этапе предварительной подготовки. После получения ваших документов, специалист компании RU-CENTER, направит запрос с вашими данными в центр сертификации THAWTE. Производитель SSL-сертификатов производит обязательную проверку корректности CSR и предоставленных документов, а также осуществляет контрольный звонок в организацию, получающую сертификат. Обычно эта процедура занимает от 3 до 10 рабочих дней, в зависимости от типа заказанного сертификата. Если домен, на который оформляется сертификат, не принадлежит организации-заказчику, от владельца домена понадобится письменное разрешение (шаблон будет предоставлен при необходимости).
Сертификат выпускается, как правило, в течение трех суток после завершения процедуры проверки данных. После выпуска сертификат будет доступен для загрузки в вашем личном кабинете. Для того чтобы получить SSL-сертификат необходимо в личном кабинете перейти "Услуги - SSL-сертификаты". В выведенном списке выберите ссылку получить сертификат. Откроется страница для скачивания SSL-сертификата. Также, для дальнейшей работы потребуется корневой сертификат центра сертификации. В нашем случае - это сертификат компании Thawte. Скачать его можно на сайте Thawte . На открывшейся странице выделите весь текст, скопируйте его в блокнот и сохраните на жестком диске под именем SSL_CA_Bundle.pem . |
1.4. Самостоятельная генерация сертификата |
|
1.4.1. Самостоятельная генерация сертификата на основе ГОСТ алгоритмов |
|
1.5. Конвертация различных форматов сертификатов в требуемый | ||
Для корректного использования сертификатов в текущем сервисе требуется, чтобы сертификаты были в формате PEM (закодированными в Base64 кодировке), аналогично формату, использующемуся в Apache. Также необходимо, чтобы сертификаты хранились каждый в своем файле, т.е.
Рассмотрим наиболее часто встречаемые форматы и способы конвертации каждого из них в PEM формат. Формат PEM. Это целевой формат, в который нужно сконвертировать свои сертификаты, в случае если они находятся в других форматах. Формат DER. Это бинарная форма PEM формата. При открытии файлов данного типа в текстовом редакторе, строки BEGIN и END отсутствуют. Конвертация из DER в PEM : openssl x509 -inform der -in c:\cert.der -out c:\cert.pem Формат PKCS#7 или P7B. Данные сертификата обычно закодированы в формате Base64, и он не может содержать приватных ключей. При открытии файлов данного типа в текстовом редакторе можно увидеть строки "BEGIN PKCS7" и "END PKCS7". Конвертация из P7B в PEM : openssl pkcs7 -print_certs -in c:\cert.p7b -out c:\cert.pem
В случае затруднения в разделении на отдельные файлы, возможно, будет проще сконвертировать полученный на предыдущем шаге PEM файл и имеющийся приватный ключ (в PEM формате) в PFX формат, который затем сконвертировать в PEM формат, с разделением на отдельные файлы: Конвертация из PEM в PFX : openssl pkcs12 -export -out c:\cert.pfx -inkey c:\cert.key.pem -in c:\cert.pem Где:
Формат PKCS#12 или PFX. Данные представлены в бинарной форме. Это файл контейнер который содержит все сертификаты - сертификат(ы) центра сертификации, сертификат домена и его приватный ключ. Конвертация из PFX в PEM :
Назначение, удаление или изменение пароля приватного ключа : openssl rsa -des3 -in c:\old_cert.key.pem -out c:\new_cert.key.pem -passin pass:old_password -passout pass:new_password Для удаления пароля не указывайте параметр passout. В случае если исходный файл без пароля, то не указывайте параметр passin. |
2. Решение проблем |
Для диагностики проблем в некоторых случаях помогает страница диагностики. Она доступна всем пользователям системы по url /.system/diag.html. Попросите удаленных пользователей воспользоваться возможностями этой страницы. |
2.1. Проблема доставки запросов от клиента к серверу |
Описание проблемы: На клиенте - проходит авторизация, проходит получение данных дерева каталогов и гридов. При этом не проходят запросы на совершение действий и не проходят запросы после задания условий отбора. На сервере - В отладочном мониторе появляются сообщения "Socket became inactive in first line" или "Bad first line". Причины проблемы: Проблема связана с особенностями провайдера клиента. У провайдера установлено ограничение на длину любого http-запроса, либо POST-запроса в 1KB или немногим более. Обычно проблема проявляется при использовании Microsoft (ISA) Internet Security and Acceleration Server на маршрутизаторе локальной сети. Для диагностики такой ситуации можно использовать командный сценарий проверки провайдера (пример) . Сценарий покажет, что отказ происходит именно при отправке запроса, размер которого превышает 1 КВ. Вы можете написать собственный сценарий проверки, лучше соответствующий вашей ситуации, и распространить его своим клиентам. Запуск файла производится из окружения интерпретатора командной строки Windows (cmd.exe) Решение проблемы лежит не в области функциональности программного продукта, а в области его эксплуатации, конкретнее - в области организации взаимодействия между web-сервером и клиентскими рабочими местами пользователей. Проблема должна решаться специалистами, отвечающими за сопровождение программного продукта у тех клиентов, у которых имеет место описанное выше ограничение. Пути решения проблемы: 1. Обратиться к провайдеру с просьбой о снятии ограничения на размер запросов. 2. Использовать нестандартный TCP/IP порт, договорившись с провайдером о его открытии с серверной и клиентской стороны. Данный путь не гарантирует решения проблемы, но может помочь. В данном случае "провайдером" может выступать как администратор локальной сети организации, так и ISP (интернет-провайдер), в зависимости от того, как организовано подключение конечного пользователя. 3. Использовать протокол https. В этом случае провайдер не сможет анализировать содержимое обмена и, следовательно, не сможет применять ограничения. Для использования протокола https необходимо иметь сертификат, а также внести изменения в настройки web-сервера. Первые два пути могут способствовать быстрому решению проблемы. При этом стратегически правильным является путь 3 - использование протокола https. Взаимодействие по протоколу https может быть организовано с использованием сертификатов двух видов: 1) Сертификат, выдаваемый уполномоченными организациями ("настоящий" сертификат). Инструкция по получению "настоящего" сертификата включена в данное руководство, а также доступна по адресу: http://app.techmill.ru/paruspub/current/documentation/ED01679A80A74E999952269A89D95D36.html 2) Самостоятельно сгенерированный сертификат. Инструкция по генерации такого сертификата приведена Здесь. При использовании самостоятельно сгенерированного сертификата браузер пользователя будет выдавать предупреждение о сомнении в его достоверности. О том как избежать отображения такого предупреждения также написано Здесь. Действия по установке настроек web-сервера для работы по протоколу https описаны Здесь. |
2.1.1. Сценарий проверки провайдера (пример) |
Содержимое примера файла сценария проверки провайдера Testme.bat 01@echo off 02IF "%1"=="" GOTO NOHOST 03 04echo Checking connection... 05AppServerFetch download %TEMP%\1.bin from http://%1/ >nul 06IF NOT %ERRORLEVEL%==0 GOTO ERROR 07echo passed. 08 09echo Checking DataMill Application Server.... 10AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml >nul 11IF NOT %ERRORLEVEL%==0 GOTO ERROR 12echo passed. 13 14echo Checking long GET.... 15AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml?data=0123456789^ 160123456789012345678901234567890123456789012345678901234567890123456789^ 170123456789012345678901234567890123456789012345678901234567890123456789^ 180123456789012345678901234567890123456789012345678901234567890123456789^ 190123456789012345678901234567890123456789012345678901234567890123456789^ 200123456789012345678901234567890123456789012345678901234567890123456789^ 210123456789012345678901234567890123456789012345678901234567890123456789^ 220123456789012345678901234567890123456789012345678901234567890123456789^ 230123456789012345678901234567890123456789012345678901234567890123456789^ 240123456789012345678901234567890123456789012345678901234567890123456789^ 250123456789012345678901234567890123456789012345678901234567890123456789^ 260123456789012345678901234567890123456789012345678901234567890123456789^ 270123456789012345678901234567890123456789012345678901234567890123456789^ 280123456789012345678901234567890123456789012345678901234567890123456789^ 290123456789012345678901234567890123456789012345678901234567890123456789^ 300123456789012345678901234567890123456789012345678901234567890123456789^ 310123456789012345678901234567890123456789012345678901234567890123456789^ 320123456789012345678901234567890123456789012345678901234567890123456789^ 330123456789012345678901234567890123456789012345678901234567890123456789^ 340123456789012345678901234567890123456789012345678901234567890123456789^ 350123456789012345678901234567890123456789012345678901234567890123456789^ 3601234567890 > nul 37IF NOT %ERRORLEVEL%==0 GOTO ERROR 38echo passed. 39 40echo Checking POST.... 41echo 01234567890 > %TEMP%\2.bin 42AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul 43IF NOT %ERRORLEVEL%==0 GOTO ERROR 44echo passed. 45 46 47echo Checking long POST.... 48for /L %%i in (1,1,100) DO echo 01234567890 >> %TEMP%\2.bin 49AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul 50IF NOT %ERRORLEVEL%==0 GOTO ERROR 51echo passed. 52 53exit /B 0 54:ERROR 55echo Failed. 56exit /B 1 57:NOHOST 58echo Host not given. 59exit /B 2 |
2.2. Клиент не может авторизоваться в системе |
Описание проблемы: На клиенте - ошибка " 403 Forbidden " при попытке входа в систему. На сервере - наблюдается неконтролируемый рост числа сессий с одного ip-адреса. Причины проблемы: Удаленные клиенты идентифицируются сервером при помощи ip-адреса и "идентификатора сессии", который поддерживается посредством механизма cookies. Механизм cookies используется следующим образом: - при первом обращении клиента к серверу, сервер генерирует идентификатор cookie (GUID) и передает его вместе с ответом клиенту; при этом каждая cookie имеет свое время жизни; время жизни задается сервером как момент времени, в который cookie будет уничтожена. Этот момент (в будущем) определяется настройкой "время жизни сессии". В соответствии с требованием стандарта для единства операций со временем (сервер и клиент могут находиться в разных часовых поясах) время указывается по Гринвичу (GMT); - клиент, получив cookie, прикрепляет ее к каждому своему дальнейшему запросу, до тех пор, пока ее время жизни не истечет; когда время жизни истекает, сервер получает запрос без cookie и выдает ошибку авторизации; - для сравнения своего текущего времени со временем на Гринвиче и сервер и клиент используют информацию о своем системном времени и своем часовом поясе. При неверной установке системного времени и/или часового пояса на сервере или на клиенте, возникнет рассинхронизация, и клиент может ошибочно считать время жизни cookie истекшим. Также очевидно, что решение проблемы лежит не в области функциональности программного продукта, а в области его эксплуатации, конкретнее - решение заключается в настройке web-сервера и рабочих мест удаленных пользователей. Проблема должна решаться специалистами, отвечающими за сопровождение программного продукта у тех клиентов, у которых имеет место описанная проблема. Пути решения проблемы:
|
2.3. Получение ответов «403 Forbidden» при некоторых действиях после успешной авторизации |
Описание проблемы: На клиенте - после успешной авторизации на некоторые запросы возвращается ошибка "403 Forbidden". На сервере - несколько запросов в рамках одной сессии приходят с одинакового ip-адреса, далее идут несколько запросов с разных ip-адресов рамках той же сессии. После этого запросы снова идут с первого ip-адреса. Причины проблемы: Ошибка происходит в момент смены видимого ip-адреса (запрос приходит на сервер не с того ip-адреса, с которого выполнялась авторизация). Иными словами, имеется проблема нестабильности ip-адреса в рамках одной пользовательской сессии. Удаленные клиенты идентифицируются сервером при помощи ip-адреса и "идентификатора сессии", который поддерживается посредством механизма cookies. Использование ip-адреса в дополнение к cookies обусловлено следующими факторами:
Пути решения проблемы:
|
2.4. Неустойчивый внешний канал |
Вопрос: - Не отображаются активные сессии в "Настройке сервиса" (используется протокол HTTP) - Наблюдается очень медленная работа веб-сервиса. Например, на авторизацию и открытие списка отчетов уходит до 10 минут. При этом запросов от BalanceOnline активных в базе нет и ресурсы веб-сервера не загружены. Ответ: Причиной описанных проблем является неустойчивый внешний канал связи. Для решения необходимо в параметрах сетевых настроек сервиса : 1. Включить сжатие трафика; 2. Снять галку "повторно использовать сессии" 3. Если предыдущие шаги не помогли, то увеличить значение параметра "Количество потоков прослушивателя" до 32. Если клиентов ожидается больше 300 (на неусточивом канале), то задать значение в 48 или даже 64 потока. Ставить большее значение не имеет смысла, в этом случае необходимо расширять внешний канал. |
2.5. Медленное открытие трафаретов, при установленном антивирусе Kaspersky |
Описание проблемы : При установленном антивирусе Kaspersky, наблюдается значительное замедление открытия трафаретов в браузере. Причина проблемы : Причиной проблемы является установленное в браузер расширение антивируса Kaspersky. Решение проблемы : Необходимо отключить это расширение в используемом браузере. Начиная с 15 версии вышеупомянутого антивируса, отключение этого расширения в браузере не достаточно, т.к. оно снова устанавливается при каждом запуске браузера. Для решения этой проблемы, необходимо отключить автоматическую установку этого расширения в самом антивирусе. Последовательность действий:
 |
2.6. Клиент не может соединиться с сервером по протоколу https с помощью Internet Explorer в Windows XP |
Клиент, используя Windows XP и Microsoft Internet Explorer, любой из доступной для этой ОС версии - 6, 7 или 8, не может соединиться с сервером по протоколу https: Это происходит по следующим причинам (какой-то одной или вместе взятых):
Решить проблему правильным и безопасным способом, это посоветовать пользователю воспользоваться другим браузером. В случаях, когда нужно принять временную меру (плохое и небезопасное решение, крайне не рекомендуется).
Рассматривайте эти меры только как временные и переводите удаленных пользователей на более современные системы. |
2.7. Клиент не может соединиться с сервером по протоколу HTTPS с помощью Internet Explorer в Windows 7 и других браузеров без TLS 1.2 |
Клиент не может соединиться с сервером по протоколу HTTPS с помощью Internet Explorer в Windows 7, а также других браузеров, не поддерживающих TLS 1.2, вне зависимости от ОС. По умолчанию, поддержка протоколов TLS 1.0 и TLS 1.1 отключена, по причине их небезопасности. Поэтому в следующих случаях клиент не сможет соединиться с сервисом по протоколу HTTPS:
Решить проблему правильным и безопасным способом, это посоветовать пользователю воспользоваться актуальной версией браузера, поддерживающий протокол TLS 1.2 и TLS 1.3. В случаях, когда нужно принять временную меру (плохое и небезопасное решение, крайне не рекомендуется).
Рассматривайте эти меры только как временные и переводите удаленных пользователей на более современные системы. |
2.8. Медленная работа удаленного клиента через приложение Win32, в случае работы через прокси сервер |
В случае работы сервиса за серверным прокси сервером и наблюдением медленной работы удаленного клиента, например есть задержки с получением ответа, в то время как на хосте сервиса видно, что данные отправились быстро, рекомендуется проверить нижеуказанные настройки сервиса:
Также стоит обратить внимание на настройки прокси сервера, касаемые буферизации ответов. Значение этих буферов должно быть как можно меньше или выключено совсем. Именование настроек для некоторых прокси серверов:
|
2.9. Поддержка долгоживущих соединений между сервером приложений и сервером СУБД (Oracle или Postgres) | ||
При длительном неиспользовании TCP соединения, роутеры между этими серверами могут начать оптимизировать использование своих ресурсов. Для этого они будут закрывать соединения, которые долго простаивали, обычно порогом является 2 ч. При этом ни сервер приложений, ни сервер СУБД не уведомляются о том, что их соединение оборвалось, и по-прежнему считают его активным. Результат подобных обрывов соединений является нежелательным ни для сервера приложений, ни для сервера СУБД и будут приводить к многочисленным проблемам, например:
Для того чтобы избежать подобных нежелательных обрывов соединений, предлагается ряд административных мер по настройке сервера СУБД для поддержания соединений в активном состоянии. Проверка и поддержание соединения активным осуществляется следующим образом. В результате пересылки таких пакетов на простаивающих соединениях будет создаваться трафик и промежуточные роутеры будут считать, что соединение необходимо и еще используется, и не будут обрывать соединения, со своей стороны. В Oracle, начиная с 12-й версии для этой механики используется настройки TCP соединений, которые хорошо описаны в следующей документации Oracle - Dead connection detection:
Таким образом, в Oracle всем этим можно управлять только через настройку SQLNET.EXPIRE_TIME. Умолчательное значение 0, т.е. выключено. Для случаев когда необходимо включить механику поддержки активности соединений, рекомендуемое значение 10 минут. В Postgres, (в 9.6 эти настройки точно уже присутствуют) есть аналогичные настройки в файле postgres.conf:
Таким образом, в Postgres всем этим можно управлять через вышеуказанные настройки в файле конфигурации postgres.conf. Для случаев, когда необходимо включить механику поддержки активности соединений, рекомендуется начать со значений, применяемых Oracle, т.к. они более продуманные и приближенные к жизни, а именно:
|
3. Ограничения и несовместимости |
3.1. Механизм описателей атрибутов документов | ||||||||||
Поддержка механизма "Описателей атрибутов документов" реализована для следующих разделов:
|
3.2. Механизм пользовательских пересчетов |
Поддержка механизмов пользовательских пересчетов реализована для раздела "Первичные/сводные отчеты". Поддерживаются только пользовательские пересчеты, основанные на хранимых процедурах (не на пользовательских). Не забудьте создать псевдоним в схеме PUBLIC для процедуры пересчета, и предоставить пользователю PUBLIС права на вызов процедуры пересчета. |
3.3. Механизм пользовательских приложений | ||||
Реализована поддержка механизмов пользовательских приложений. Поддерживаются пользовательские приложения на основе модулей, разработанных на языке VBscript . Скрипт выполняется в адресном пространстве сервиса. Поддерживаются доступные объекты, переменные, функции, описанные в документации ПП Парус 8 для скриптовых модулей пользовательских приложений, с учетом следующих ограничений и дополнений:
Механизм автоматической загрузки и регистрации зависимых модулей не поддерживается. Администратор сервера обязан самостоятельно обеспечить доступность COM-объектов, используемых в скриптах пользовательских приложений, с учетом разрядности редакции сервиса.
|
3.4. Механизм детального контроля прав доступа |
Механизм поддерживается в разделах "Первичные/Сводные очеты", "Формы отчетов" и "Контрагенты". Поддерживаются только предикаты, связанные со следующими объектами:
|
Whois2 
