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

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

Признаками данной проблемы являются:

Невозможно зайти в информационную базу.

Почти 100% активность диска, на котором расположен журнал регистрации и активное чтение файла журнала регистрации процессом rmngr.
Данный пункт можно проверить с помощью монитора ресурсов (Диспетчер задач - Производительность - Открыть монитор ресурсов) на вкладке “Диск”.
В группе “Запоминающие устройства” нужно обращать внимание на колонку “Активное время (%)”.
В группе “Работа диска” нужно обращать внимание на колонки “Чтение” и “Файл”. Можно отсортировать по колонке “Чтение”. Среди первых строк с максимальной скоростью чтения будет процесс rmngr. Далее нужно смотреть имя читаемого файла, оно будет соответствовать журналу регистрации определенной информационной базы.

В консоли администрирования кластера серверов 1С:Предприятие в списке сеансов почти у всех пользователей будет большое и приблизительно одинаковое значение в колонке “Захвачено СУБД” или в колонке “Время вызова (текущее)”.

При обнаружении проблемы нужно:

Запомнить УИД ИБ, к которой выполняется чтение процессом rmngr.

Запустить сбор технологического журнала на события EXCP, если еще не запущен.

Сделать экспорт всех сеансов на проблемном сервере ИЛИ на проблемной ИБ с помощью консоли администрирования кластера серверов 1С:Предприятие, на случай, если понадобятся дополнительные данные для анализа.

Перезапустить службу 1С:Предприятие.

Собрать технологический журнал на время перезапуска сервера 1С:Предприятие.

Проанализировать технологический журнал: выполнить поиск слов “ВыгрузитьЖурналРегистрации” или “UnloadEventLog”.

Пример:

29:40.069000-0,EXCP,4,process=rphost, p:processName=ib_accounting ,t:clientID=114396,t:applicationName=1CV8C, t:computerName=COMP ,t:connectID=109127,SessionID=1, Usr=ИвановИИ ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=Передача данных прервана по инициативе принимающей стороны.,Context="Форма.Вызов: ВнешнийОтчет.АнализЖурналаРегистрации.Форма.Модуль.ФоновоеЗаданиеЗапустить

ОбщаяФорма.ФормаОтчета.Форма: 1242: ВариантыОтчетов.СформироватьОтчетВФоне(ПараметрыФормированияОтчета, РезультатФоновогоЗадания.АдресРезультата);

ОбщийМодуль.ВариантыОтчетов.Модуль: 2544: Формирование = СформироватьОтчет(Параметры, Ложь, Ложь);

ОбщийМодуль.ВариантыОтчетов.Модуль: 2060: ОтчетОбъект.СкомпоноватьРезультат(Результат.ТабличныйДокумент, Результат.Расшифровка);

ВнешнийОтчет.АнализЖурналаРегистрации.МодульОбъекта: 64: ВыгрузитьЖурналРегистрации (ТЗ,Отбор,Колонки);"

По этой строке можно сказать кто: ИвановИИ, где (на каком компьютере): COMP , в какой информационной базе: ib_accounting запустил анализ журнала регистрации.

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

Последствия могут быть самые разные, а именно:

• Не поданная в сроки заявка на участие в конкурсе
• Проигранный электронный аукцион
• Не подписанный в срок государственный контракт

Три наиболее распространённые проблемы в работе с электронной подписью

1. Сертификат участника закупки не отображается на электронной площадке
2. Электронная подпись не подписывает документы

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

Самое главное — запомнить, что для корректной работы электронной подписи необходимо использовать браузер Internet Explorer не ниже 8 версии и, желательно, не выше 11 (с 11 версией нет гарантий стабильной работы подписи).

Сертификат ключа подписи не виден на площадке при попытке входа в систему

В данном случае ошибка вызвана сразу несколькими причинами, а именно:

• Некорректная настройка сертификата ключа подписи
• Неправильно настроен интернет браузер
• Отсутствует корневой сертификат Удостоверяющего Центра

Как решить проблему?

В первую очередь, необходимо убедиться в том, что Вы корректно установили открытую часть сертификата в личные через СКЗИ (Крипто Про). При этом версия установленной программы подходит для типа вашей операционной системы.

Затем, в настройках браузера Internet Explorer необходимо добавить адреса площадок в надежные узлы и включить все элементы ActiveX.

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

Как правило, эта ошибка возникает в ряде случаев:

• Истек срок действия лицензии программы КриптоПро
• Вставлен носитель с другим сертификатом

Как это исправить?

Для этого Вам необходимо получить новую лицензию, обратившись в Удостоверяющий Центр. После того, как лицензия благополучно получена, необходимо запустить КриптоПро и ввести серийный номер лицензии.

Во втором случае Вам необходимо проверить все закрытые контейнеры (носители), вставленные в USB-разъем компьютера и проверить правильность выбора нужного сертификата.

Система выдает ошибку при входе на электронную площадку

Данная ошибка может быть вызвана совокупностью причин, указанных выше. Как показывает практика, такая ошибка в первую очередь появляется из-за неправильно установленной библиотеки Capicom. Рекомендуем проверить наличие установленной библиотеки на Вашем компьютере и обратить внимание на необходимость копирования 2 системных файлов с расширением.dll в одну из папок Windows, при пользовании 64-разрядной системой.

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

COMET-технологии позволяют организовать обновление данных на странице без участия пользователя.

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

В этом цикле статей - подробно описаны многочисленные тонкие моменты и решения частых проблем.

Что такое COMET ?

COMET (или "server push") - способ передачи данных с сервера на клиент, по инициативе сервера.

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

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

Старейший пример COMET - чат. Человек просто находится на странице и получает новые сообщения.

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

Способы реализации

Способов реализации COMET достаточно много. У них - самые разные характеристики, достоинства и недостатки.
Есть два основных класса.

По сообщению на запрос

Каждое событие на сервере браузер получает отдельным запросом. Здесь есть два основных метода.

1. Частый опрос (polling)
2. Длинный опрос (long-poll)

Чтобы уменьшить количество необходимых соединений и задержки, сообщения о событиях пакуют в специальные пакеты, "датаграммы".
Например, одно XML-сообщение может выглядеть как:

Vasya Привет! processing Обработка завершена

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

Браузер держит постоянное соединение с сервером, так называемый "канал", и получает через него события.

Канал связи разрывается время от времени:

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

Кроме того, для измерения сетевых задержек и контроля соединения, сервер может периодически посылать по этому каналу ping-пакеты.

Основные способы поддержания постоянного соединения:

1. Бесконечный IFrame
2. XMLHTTPRequest, interactive
3. Multipart XMLHTTPRequest
4. Event-source

Вы найдете их в других статьях этого раздела.

Общие для постоянных соединений проблемы

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

Буферизация прокси

Такое встречается редко, но прокси может буферизовать определенное количество данных до передачи клиенту. Например, принимать и отдавать ответ блоками по 2К. В этом случае сообщения будут оставаться на прокси, и ждать, пока их не наберется 2К (или какой там размер буфера) байт, и только тогда - передаваться клиенту.

Решение - добавлять к каждому сообщению 2K пробелов.

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

Нельзя GZIP

IFrame, который служит для передачи сообщений, НЕ должен сжиматься gzip/deflate. Иначе говоря, для служебного URL сообщений сжатие должно быть отключено.

Включенное сжатие подразумевает, что браузер ждет конца загрузки, а затем - распаковывает и показывает пользователю. В нашем же случае это категорически противопоказано, а сжимать кусочки страницы (сообщения) по отдельности нельзя.

Это - неприятное последствие хакерской натуры iframe. Например, в long poll сжатие проходит на ура, т.к события не являются частью одной страницы.

Буферизация страницы сервером

Не забудьте отключить буферизацию сервером. В связке Apache/PHP - отключите output buffering и включите ob_implicit_flush:

While (@ob_end_flush()) {} ob_implicit_flush(1); // ну и конечно убрать лимит на время выполнения скрипта set_time_limit(0);

COMET: частый опрос VS постоянное соединение

Как всегда, при написании веб-приложения встает вопрос о выборе архитектуры. С одной стороны, решения на длинных соединениях (все, кроме частых опросов) обеспечивают быстрое уведомление. С другой... Всегда ли длинное соединение лучше частых опросов?
Решение с длинными соединениями с виду оптимальнее, но гораздо сложнее и обладает рядом особенностей.

1. Реализация длинного коннекта, как правило, усложняет архитектуру. Возможно, можно обойтись решением попроще?
2. Ряд веб-серверов плохо оптимизированы под большое количество длинных соединений. Например, используются потоки или процессы, которые отъедают фиксированное количество ресурсов и не освобождают их до конца соединения.На уровне OS проблема решается использованием kqueue(FreeBSD) или epoll(Linux).На уровне веб-сервера можно использовать
   1. Apache MPM event для apache 2.2 (экспериментальный и ограниченный MPM, специальный поток обрабатывает Listening и Keep-Alive сокеты)
      не работает как следует с mod_perl/mod_php
   2. Jetty (Java) / Twisted(Python), nginx и другие специализированные серверы c одним потоком/процессом на много клиентов.

   Потянет ли текущая серверная архитектура длинные соединения? Ответ неочевиден для сотен/тысяч одновременных соединений, но, скажем, до 100 соединений в любой архитектуре все хорошо.

3. Насколько долго пользователи находятся на одной и той же странице? При переходах коннект, скорее всего, придется открывать заново в любом случае.
4. Если допустимы задержки доставки событий, то, может быть, хватит частого опроса?

Классическая(transport-independant) модель COMET

Посмотрим на взаимодействие клиент-сервер "с высоты птичьего полета", выше деталей передачи данных, транспортов и т.п. Например, так это сделано в специализированном server-push движке lightstreamer.

Соединения с сервером делятся на два типа

1. Control connection - контрольные соединения, через которые клиент отправляет запросы на сервер. Это - обычные AJAX-запросы через XMLHTTPRequest.
2. Push connection(channel) - поток событий, соединение, через которые клиент получает события с сервера

У всех событий на сервере есть тип. Клиент может подписываться и отписываться на интересующие его события через контрольные соединения. Для удобства типы организованы по схемам. Например, в схеме chat может быть тип message.

Например, следующая диаграмма описывает типичную последовательность действий:

1. Клиент открывает потоковое соединение к серверу
2. Клиент подписывается на события типа Item1 в схеме Schema1
3. Сервер шлет события
4. Клиент отписывается от событий через новое контрольное соединение
5. Клиент закрывает соединение

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

В качестве транспорта в lightstreamer используется iframe. Время от времени его необходимо закрывать для очистки от принятых объектов. При закрытии сессии (это же происходит при refresh страницы в браузере) сервер буферизует новые события до некоторого таймаута и отдает их, как только открывается новая сессия Stream Connection 2 того же пользователя.

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