Аксессуары

Передача информации с сервера. Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов

Статья продолжает цикл статей «Первые шаги в разработке на 1С».

В ней мы рассмотрим способы информирования пользователя, которые присутствуют в платформе «1С:Предприятие» 8, а также акцентируем ваше внимание на некоторых особенностях работы этих механизмов, эти особенности связаны с режимом использования модальности.

Применимость

В статье рассматривается функциональность:

  • Интерфейса в варианте «Версии 8.2» для конфигурации, разработанной на платформе «1С:Предприятие» 8.2.19.130
  • Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.4.496 до 8.3.9+
  • Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.10-8.3.11

Как в 1С вывести сообщение пользователю

Вывод сообщений в пользовательском режиме решает ряд задач:

  • отражение хода выполнения текущего процесса (показ стадии выполнения процесса; показ расчетных значений, полученных в ходе работы алгоритма);
  • выдача ошибок пользователю для возможного их исправления;
  • выдача рекомендаций;

Типы сообщений:

  • терминирующие, которые останавливают выполнение программы и не дают продолжить ее, пока пользователь не ознакомится с этим сообщением и не выполнит определенные действия. Например, на экран пользователю будет выдан вопрос, на который нужно будет ответить Да или Нет. Пока пользователь не ответит – программа не выполняет дальнейшие действия;
  • ознакомительные сообщения, которые просто выводятся для пользователя и позволяют работать дальше (т.е. используются в режиме оповещения).

Терминирующими сообщениями должны быть сообщения об ошибках, а ознакомительными: рекомендации, сообщения о текущем этапе процесса и показ расчетных значений (отладочная печать).

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

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

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

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

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

Открепить от формы окно с сообщением нельзя.

Синтаксис функции:

Сообщить (<Текст сообщения>, <Статус>)

Т.е. первым параметром является сам текст.

Второй параметр (статус сообщения) является необязательным. Для статуса можно указывать значения: Обычное , Важное , ОченьВажное и т.д.

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

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

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

Пользователь нажимает на кнопку Записать и закрыть , в этом случае сообщение выводится в соответствующее окно (справа формы).

Но форма моментально закрывается, и пользователь не увидит, что для него выводилась какая-то информация.

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

Тем не менее, функция Сообщить может использоваться для вывода информации о некоторых ошибках, например в момент проведения документа.

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

Функция Сообщить полностью поддерживается в Платформе 8.3. Ее можно использовать, и она будет работать (и в файловом варианте, и в клиент-серверном).

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

Например, сообщение об ошибке можно привязать к элементу формы, что для пользователя очень наглядно. Несколько позже к рассмотрению этого вопроса мы вернемся. У функции Сообщить есть интересная особенность.

Так, программный код в Платформе 8.3 может быть исполнен как на стороне Клиента, так и на стороне Сервера.

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

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

Но функция Сообщить может быть исполнена как на стороне Клиента, так и на стороне Сервера. При этом использование метода Сообщить на Сервере вовсе не означает, что сообщение будет выводиться именно на Сервере, там их просто некуда выводить.

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

В этот момент система запросит данные из буфера и выведет их на экран.

Эта же особенность касается и класса СообщениеПользователю . На рисунке приведен пример использования метода Сообщить на стороне Сервера.

В результате использования метода Сообщить на стороне Сервера вывелись сообщения на экран на стороне Клиента.

Механизм оповещений нужен, чтобы информировать пользователя о том, что в системе “что-то” произошло и это “что-то” требует внимания пользователя. Оповещения создаются двумя сценариями:

  1. Самой платформой при интерактивной записи или изменении объекта
  2. Разработчиком при вызове в коде метода .

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

Кроме того, к оповещениям можно обратиться в соответствующей области информационной панели (кнопка “История” слева внизу формы приложения в варианте интерфейса «Версии 8.2»).

Чтобы создавать свои собственные оповещения, необходимо использовать метод глобального контекста ПоказатьОповещениеПользователя() . Его синтаксис до редакции 8.3.10 представлен ниже:

ПоказатьОповещениеПользователя (<Текст>, <НавигационнаяССылка>, <Пояснение>, <Картинка>)

В первом параметре передается текст, который будет выводиться в оповещении.

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

С помощью третьего параметра можно передать пояснение для сообщения, т.е. какое-то расширенное описание.

Также можно присвоить картинку, отображающую статус оповещения.

Следует отметить, что все эти параметры являются необязательными для заполнения. Ниже приведен пример использования данного метода (в конфигураторе и в пользовательском режиме в варианте интерфейса «Версии 8.2»).

В редакции платформы 8.3.10.216 для интерфейса в варианте «Такси» механизм оповещений был существенным образом доработан с целью повышения удобства работы как в тонком, так и в веб-клиенте. По этой причине изменились и передаваемые параметры в метод ПоказатьОповещениеПользователя() . Теперь синтаксис выглядят так:

ПоказатьОповещениеПользователя(<Текст>, <ДействиеПриНажатии>, <Пояснение>, <Картинка>, <СтатусОповещенияПользователя>, <КлючУникальности>)

Видно, что второй параметр, ранее называемый НавигационнаяСсылка , получил новое имя ДействиеПриНажатии . Это связано с тем, что теперь в него стало возможным передавать не только строку с навигационной ссылкой, но и описание оповещения. Это проиллюстрировано скриншотом ниже:

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

Следующий параметр СтатусОповещенияПользователя появился впервые. В нем указывается статус оповещения (Информация или Важное).

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

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

В панели инструментов появилась кнопка с пиктограммой звонка, по которой вызывается упомянутый выше Центр оповещений. В нем накапливаются новые важные оповещения, на которые пользователь пока никак не отреагировал.

Если в Центре есть какие-то оповещения, то рядом с ним появляется маленькая оранжевая точка, чтобы привлечь внимание пользователя. Пользователь может открыть Центр оповещений, прочитать текст и, если необходимо, выполнить какие-то действия.

Из Центра оповещение убирается нажатием на кнопку очистки, однако если с оповещением связано какое-то действие, то, как только пользователь щелкнет мышью по тексту сообщения, оно тоже пропадет.

И наконец, последним добавленным параметром стал КлючУникальности . С его помощью можно найти отображенное на экране оповещение и изменить его. Если же оповещения с таким параметром нет, то будет показано новое оповещение.

Как видим, возможностей, предоставляемых соответствующим методом, стало еще больше! Но это не все изменения в механизме оповещений.

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

Также к новым возможностям относится и одновременное отображение на экране до трех оповещений.

На этом завершим наше знакомство с программным формированием оповещений. Однако вспомним, что оповещения формируются не только разработчиком программно, но и самой платформой в момент интерактивной записи или изменения объекта. И часто этот факт вызывает непонимание в первую очередь у начинающих пользователей: зачем нужны эти служебные оповещения, которые, кстати, нельзя отключить?

Давайте представим такую простую ситуацию: пользователь установил фильтр в каком-то списке для удобства. Допустим, он сделал это в форме списка справочника Номенклатуры. Потом, через какое-то время, решил ввести новый элемент с наименованием “Стул”, который не соответствует установленному ранее фильтру. Вводит его, записывает и…? И не видит его в списке. Что будет делать среднестатистический пользователь? Конечно, введет его второй раз, но опять не увидит. Дальше может последовать третий, четвертый, пятый раз. Когда ему надоест вводить одно и тоже, он, наконец, спросит у вас: а куда все пропадает?

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

Терминирующие сообщения

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

О возможности использования терминирующих сообщений в Платформе 8.3 мы поговорим немного позже (в последнее время их стараются не использовать, поэтому рассмотренный пример больше касается Платформы 8.2).

Существуют два метода для выдачи терминирующих сообщений Предупреждение и Вопрос . Предупреждение отличается от Вопроса тем, что у него есть единственная кнопка ОК .

В вопросе могут определяться разные наборы вариантов ответов (ДаНет , ДаНетОтмена , ОК , ОКОтмена , ПовторитьОтмена , ПрерватьПовторитьПропустить ), которые задаются с помощью параметра.

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

Предупреждение(“Сейчас будет открыта база”);

Чтобы открыть модуль управляемого приложения, следует в дереве конфигурации выбрать объект Конфигурация , вызвать контекстное меню и выбрать пункт Открыть модуль управляемого приложения .

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

Аналогичным образом работает и функция Вопрос .

Синтаксис:
Вопрос(<ТекстВопроса>,<Кнопки>,<Таймаут>,<КнопкаПоУмолчанию>,<Заголовок>,
<КнопкаТаймаута>);

Обязательными являются только первые два параметра. Для второго параметра тип данных составной (РежимДиалогаВопрос или СписокЗначений ). Третий параметр (<Таймаут> ) характеризует интервал времени в секундах, в течение которого система будет ожидать ответа пользователя.

По истечении интервала окно вопроса будет закрыто. Аналогичный параметр(<Таймаут> ) есть и у функции Предупреждение .

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

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

Особенности использования модальных окон в Платформе 8.3

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

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

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

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

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

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

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

Эти методы позволяют вызывать окно, но не останавливать выполнение программного кода. Технически это реализуется формированием псевдоокна внутри родительского окна. Псевдоокно не перекрывает родительское окно. После открытия такого окна код продолжает выполняться.

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

Синтаксис функции ПоказатьПредупреждение :

ПоказатьПредупреждение(<ОписаниеОповещенияОЗавершении>, <ТекстПредупреждения>, <Таймаут>, <Заголовок>)

Параметр <ОписаниеОповещенияОЗавершении> (необязательный)

Тип данных: ОписаниеОповещения .

Содержит описание процедуры, которая будет вызвана после закрытия окна предупреждения.

Синтаксис функции ПоказатьВопрос :

ПоказатьВопрос(<ОписаниеОповещенияОЗавершении>, <ТекстВопроса>, <Кнопки>, <Таймаут>, <КнопкаПоУмолчанию>, <Заголовок>, <КнопкаТаймаута>)

Обязательными являются первые три параметра.

Ниже приведен пример использования функции.

Класс СообщениеПользователю

Основное удобство класса сообщений СообщениеПользователю заключается в том, что это контекстное сообщение (в отличии от методов Предупреждение и Вопрос ).

Сообщения могут быть привязаны к конкретному экранному элементу. Этот объект доступен и на Сервере.

Следует обратить внимание, что, во-первых, данный объект нужно создавать. Например: Сообщение = Новый СообщениеПользователю;

Таким образом мы создаем экземпляр данного объекта.

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

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

Внимание! Для привязки к нужному полю формы обратите внимание на инициализацию свойств ПутьКДанным и КлючДанных . Применительно для документа при размещении кода в модуле объекта можно писать:

Сообщение.ПутьКДанным = “Объект”;
Сообщение.КлючДанных = ЭтотОбъект.Ссылка;

Чтобы открыть модуль документа, следует в окне редактирования объекта (документа) на закладке Прочее нажать на кнопку Модуль объекта .

Для эксперимента в модуле объекта какого-либо документа разместим код.

Ниже представлен полученный в пользовательском режиме результат для Платформы 8.3.

Следует отметить, что сообщения, выводимые с помощью нового объекта системы СообщениеПользователю в общем случае не являются терминирующими. Т.е. система позволит пользователю продолжить дальнейшие действия не отреагировав на выводимые сообщения.

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

Соответственно, в момент обнаружения ошибок отменяется транзакция, т.е. запрещается запись элемента справочника, либо запрещается проведение документа.

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

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

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

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

Синтаксис: Состояние(<ТекстСообщения>, <Прогресс>, <Пояснение>, <Картинка>)
Параметры: <ТекстСообщения> и <Пояснение> – не обязательные, тип – Строка .
Текст выводится на специальную панель состояния.
<Прогресс> параметр тоже необязательный, но наглядный.
Тип: Число . Значение индикатора прогресса (от 1 до 100).
<Картинка> тоже необязательный параметр.
При обработке какого-либо события могут использоваться периодические вызовы функции типа:

При этом могут меняться надписи, а могут изменяться значения параметра Прогресс.

Функция может вызываться как из одной процедуры (функции), так и из нескольких. Таким образом можно отслеживать состояние выполнения процесса.

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

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

Хочется еще раз акцентировать ваше внимание на том факте, что если ваша конфигурация (версии 8.3.3+) предполагает работу с помощью веб-клиента, то:

  • на уровне конфигурации должна быть установлена настройка режима модальности «Не использовать»
  • в коде должны использоваться методы асинхронной модели взаимодействия с пользователем. Такие методы начинаются со слов Показать или Начать .

Более подробно об отказе от использования модальных окон в платформе 1С:Предприятие 8.3 можно почитать в финальной статье цикла . А мы идем дальше и, наконец, приступаем к изучению долгожданного интерфейса «Такси» , который уже не раз упоминался в наших материалах.

В программах на платформе 1С:Предприятие сообщение пользователю можно показать разными способами.

1. Метод ПоказатьПредупреждение .

ПоказатьПредупреждение(< ОписаниеОповещенияОЗавершении> , < ТекстПредупреждения> , < Таймаут> , < Заголовок> )

При использовании этой конструкции окно с предупреждением возникает в центре интерфейса программы.

Параметры:

ОписаниеОповещенияОЗавершении (необязательный)
Тип: ОписаниеОповещения. Содержит описание процедуры, которая будет вызвана после закрытия окна предупреждения со следующими параметрами: ДополнительныеПараметры - значение, которое было указано при создании объекта ОписаниеОповещения. Если параметр не указан, то по завершении никакая процедура вызвана не будет.

ТекстПредупреждения (обязательный)
Тип: Строка; ФорматированнаяСтрока. Текст предупреждения.

Таймаут (необязательный)
Тип: Число. Интервал времени в секундах, в течение которого система будет ожидать ответа пользователя. По истечении интервала окно предупреждения будет закрыто. Если параметр не указан, то время ожидания не ограничено. Если параметр имеет отрицательное значение, будет сгенерировано исключение. Значение по умолчанию: 0.

Заголовок (необязательный)
Тип: Строка. Содержит заголовок окна предупреждения. Описание: Выводит на экран окно предупреждения, но не ожидает его закрытия.

Доступность: Тонкий клиент, веб-клиент, толстый клиент, мобильное приложение(клиент).

Примечание: Если после закрытия пользователем окна предупреждения должен быть выполнен какой-либо код, то его нужно разместить в отдельной процедуре модуля и описать ее в параметре.

2. Метод Предупреждение .

Окно с предупреждением возникает в центре интерфейса программы. Однако, если для конфигурации свойство РежимИспользованияМодальности установлено в НеИспользовать , то метод не работает.

Доступность: Тонкий клиент, веб-клиент, мобильный клиент, толстый клиент, мобильное приложение(клиент).

3. Метод ПоказатьОповещениеПользователя .

ПоказатьОповещениеПользователя(< Текст> , < ДействиеПриНажатии> , < Пояснение> , < Картинка> , < СтатусОповещенияПользователя> , < КлючУникальности> )

При использовании этого метода сообщение появляется в правом нижнем углу интерфейса.

Доступность: Тонкий клиент, веб-клиент, толстый клиент.

4. Метод Сообщить .

Сообщить(< ТекстСообщения> , < Статус> )

Доступность: Тонкий клиент, веб-клиент, мобильный клиент, сервер, толстый клиент, внешнее соединение, мобильное приложение(клиент), мобильное приложение(сервер).

5. Объект СообщениеПользователю .

Предназначен для хранения параметров сообщения, которые необходимо вывести пользователю. Если сообщение еще не было показано пользователю (такое может быть при работе на стороне сервера, в фоновом задании, внешнем соединении или Web-сервисах), можно получить накопленные сообщения методом ПолучитьСообщенияПользователю .

Свойства: ИдентификаторНазначения (TargetID); КлючДанных (DataKey); Поле (Field); ПутьКДанным (DataPath); Текст (Text).

Методы: Сообщить (Message); УстановитьДанные (SetData).

Сообщение появляется в нижней части интерфейса, в строке.

Сообщение = Новый СообщениеПользователю() ; Сообщение. Текст = "Не хватает номенклатуры " ; Сообщение. Поле = "Номенклатура.Количество" ; Сообщение. УстановитьДанные(ОбъектДанных) ; Сообщение. Сообщить() ;

Сначала самое главное. Для “нормальных” IT служб этот вопрос не существуют. Люди с опытом на практике выясняют почему плохо на терминальные сервера помещать другие задачи и так не делают. Но мы все прекрасно понимаем, что есть маленькие компании, а так же всегда есть те кто начинают и соответственно этого опыта не имеют. Поэтому возможно даже кому то дальше и покажется объяснение банальным, но его надо озвучить.
Рассмотрим совмещение терминалки с остальными ролями серверов с “обеих” сторон.

1. “За совмещение”.
Основная НАСТОЯЩАЯ причина совмещения ролей — это экономия денег. А если быть точным — КАЖУЩАЯСЯ экономия на старте эксплуатации.
Конечно многие сторонники приводят другие аргументы. Но они как правило в итоге всё равно “конвертируются” в дешевизну. Кстати, что будет дальше после начала эксплуатации в этот момент сторонники совмещения плохо просчитывают — позиция проста — “прорвемся как-нибудь”.

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

Есть такая вещь как запас мощности оборудования в пиковые моменты. К сожалению многим администраторам не очевидно, что когда он смотрит в диспетчер задач он видит моментальный снимок (несколько минут) текущий загруженности и не видит «пиков». И не увидит.
У разных ролей сервера максимальная амплитуда между «пиком» и средним значением может сильно отличаться. В среднем по больнице, роль терминального сервера характеризуется наибольшей разницей между нагрузкой в пике и средней нагруженностью. Можно дать условное объяснение, но оно условное: руками вбивая данные (один документ раз в пять минут) очень тяжело на стороне клиентской части 1С вообще что либо нагрузить, так как манипуляции с данными, обсчет и т.п. выполняется на другом сервере (сервере 1С и субд). Т.е. пользователи делая что то руками, а это большая часть рабочего дня не сильно то и грузят терминальный сервер. Зато когда возникает некоторая локальная задача не на весь день — скопировать фильм, скачать дистрибутив, выполнить загрузку данных на клиент, да хоть тореннтом порно скачать — все это неплохо кушает ресурсы, пусть и не длительное время, но часто несколько ядер процессора грузятся целиком. А еще есть антивирус, который не должен стоять на сервере 1С (куда нет локального доступа у пользователей) , но зато антивирус обязательно должен стоять на терминальном сервере. Еще на терминальном сервере хорошим тоном последние годы должен стоять антишифровальщик. Такие «штуки» хоть и не постоянно, но иногда что то начинают проверять — новый файл, атаку портов и т.п. Вообщем, называйте это как хотите, но периодически на терминалки бывают ситуации, особенно когда железка загруженна сверхсильно. Это ведь пулл терминалок — это лишь опытные админы делают, балансируя соединения и нагрузку. Я уж молчу про dfss, квотирование ресурсов, виртуализацию и т.п. обрезающие любому потоку максимальную скорость.

1. “За разнесение”. Получается что не только надо говорить о регулировании нагрузки между ролями. Регулировать нагрузку надо между терминальными пользователями. А при количестве превышающим разумное для одного сервервера надо строить несколько терминальных серверов, раскидывая пользователей между ними.
Не совсем теория, но тоже интересный факт. Наша практика показала (а мы делаем порядка 100 аудитов в год), что пики загруженности терминальных серверов при совмещение с сервером 1С — это очень популярный вариант и оказалось что терминальные сервера не мониторятся вообще или делается это условно, но главное сильно влияют на работу других ролей сервера (сервера 1С в данном случае). Причем это не теоретическое рассуждение — выносили нагрузку на отдельный сервер и клиент подтверждал положительный результат.
2. “За разнесение”. Еще один фактор — это лицензирование. На одно и тоже количество пользователей (понятно что мы говорим не про трех человек) с учетом большой разницы в стоимости между стандартом и энтерпрайзом выгоднее собирать в пул несколько недорогих серверов, чем одну мощную “железку”. Наример, если вы лицензируете MS SQL Server, то Вам надо лицензировать ВСЕ ядра сервера, а не те, которые вы аффинити маской назначите использовать. Получается, что Вы переплатите за пользователей, который будут съедать процессоры терминальными сессиями.

3. “За разнесение”. Настоящий аргумент это безопасность. Причем это многогранная вещь. Терминальные сервера стоит активно мониторить антивирусом. Это наиболее вероятно место атаки для троянов, шифровальщиков, брутфорсов и т.п. А вот на сервер с ролью сервера 1С и субд локально лучше вообще не заходить. Консоли правления лучше запускать с другого сервера. Активно проверять антивирусом сервера 1С, их соединения — бррр. Вы скорее всего пожалеете об этом. И уж тем более “грех” на сервере 1С или субд устраивать “файловую помойку”. Впрочем в России безопасностью пока не клюнет — не занимаются, поэтому идем дальше.

4. “За разнесение”. Обычно в момент покупки сервера задача “кто будет разбираться с проблемами конкуренции за ресурсы” серьезно не воспринимается. Но на практике еще можно понять тех, кто роль сервера 1С и субд сажает на “физику”, а рядом ставит виртуалку и в неё помещает “терминальный сервер”, так хотя бы терминальные пользователи имеют меньше приоритет в борьбе за ресурсы, и их легче заквотировать. Но почему не очевидно, что чтобы квотировать надо понимать НА ОСНОВАНИИ КАКИХ МЕТРИК КАКИЕ ПРАВИЛА ПРИМЕНЯТЬ. А кто серьезно мониторит нагрузку терминальных пользователей. А тек кто могут настроить,например “заббикс”, все равно не могут интерпретировать правильно собранные значения. Другими словами, лень — это нормальная черта админа, но надо правильно оценивать свои силы. Заизолировать нагрузку физически гораздо реалистичней, чем думать, что в процессе эксплуатации у вас вдруг откроется второе дыхание и вы найдете потайные галочки которые вернут нагрузку в норму.
Взять аналогию с кораблями. У них есть “переборки”, для того чтобы в случая пробоя ниже ватерлинии попавшая внутрь вода не распространилась по всему объему корабля и не привела к затоплению. Наивно думать, что когда этот пробой произойдет, то вы займетесь созданием этих самых перегородок. Да ни черта у Вас не будет времени/денег/знаний/желания на это занятие.

А если Вы — маленькая компания, то рядом с клиент-серверным вариантом частенько бывает файловая версия например 1С:Бухгалтерии. И эту базу надо размещать не на сервере субд, а на терминальном сервере на локальных дисках, а не по сети. Иначе вы ухудшите работу файлового варианта.

Хотите поступить правильно — лучше выбейте денег на отдельную терминалку.
Ну а если хотите глубже погрузиться в эту тему, приходите на наш тренинг http://www..
Не согласны с материалом — напишите slava@сайт ваши аргументы.. Обе позиции включим в обзорный материал выше.

Улучшен механизм счетчиков потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров).Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

Реализован пакетный режим работы тонкого и толстого клиентских приложений. Пакетный режим распространяется от начала запуска клиентского приложения до окончания работы обработчика ПередНачаломРаботыСистемы модуля приложения. После окончания работы обработчика пакетный режим автоматически отключается. В пакетном режиме запуска подавляется вывод любых диалогов системы. Признаком пакетного режима работы клиентского приложения является команда командной строки запуска /DisableStartupDialogs .

Больше не поддерживается интерфейс 8.2

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

  • пересчет итогов во время операции Тестирование и исправление из конфигуратора;
  • использование метода ПересчитатьИтоги() при выполнении следующих условий:
    • монопольный доступ к информационной базе;
    • наличие административных прав у пользователя, от имени которого выполняется пересчет итогов;
    • метод исполняется в сеансе, в котором не используется ни одного разделителя.

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB .

Для регистра расчета реализован кластерный индекс по регистратору. Перестройка индекса будет выполнена при реструктуризации регистра расчета или при переиндексации во время выполнения операции тестирования и обновления.Если при удалении записей из таблицы фактического периода действия не установлен отбор по измерениям регистра, то для запроса удаления не формируется соединение с основной таблицей регистра. Снижена вероятность табличной блокировки при удалении записей фактического периода действия регистра расчета.

В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие ) помещаются планы запросов для запросов UPDATE , DELETE и INSERT . (Раньше был только SELECT)

Реализовано отображение критических ошибок оптимизированного механизма обновления конфигурации базы данных в конфигураторе и в событии технологического журнала.

В технологическом журнале реализованы свойства Dbms , Database , DBCopy для событий обращения к СУБД (DB2 , DBMSSQL , DBPOSTGRS , DBORACLE ), событий EXCP и SDBL .

Рубрика: , | Метки: ,

Оптимизация работы с PostgreSQL
Оптимизирована работа виртуальных таблиц оборотов регистров накопления и бухгалтерии в случае использования группировок по дню, месяцу или году, а также при использовании функции языка запросов НачалоПериода() . Оптимизация используется для любых версий поддерживаемых СУБД, кроме Microsoft SQL Server, где оптимизация действует, начиная с версии 2012.

факты превышения счетчика фиксируются в технологическом журнале (событие )

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

  • за текущий серверный вызов;
  • за последние 5 минут;
  • за все время работы сеанса.

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

Изменение структуры.
Для регистров сведений реализовано формирование кластерного индекса по измерениям для физических таблиц среза первых и среза последних. Описание структуры индекса (см. ). Отключен контроль уникальности индексов. Оптимизированы запросы получения данных из таблиц срезов. Построение новых индексов выполняется во время реструктуризации соответствующего регистра сведений или при выполнении реструктуризации базы данных во время выполнения операции тестирования и исправления.

Новые конструкции запросов. Реализована возможность создания поля с уникальными (в рамках одной таблицы), последовательно возрастающими значениями. Реализована функция языка запросов АВТОНОМЕРЗАПИСИ() , которая может быть использована только при создании временной таблицы.Не поддерживается использование функции АВТОНОМЕРЗАПИСИ() :

  • в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;
  • в запросах, не формирующих временную таблицу;
  • вне списка выборки;
  • в выражениях.

Реализован объект КонстантаКлючЗначения .Для менеджера константы реализованы методы СоздатьКлючЗначения() .

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

Оптимизация для облаков .
Уменьшен размер временных файлов, создаваемых платформой при обновлении индекса полнотекстового поиска. Данное изменение наиболее заметно в информационных базах с большим количеством разделителей. Новый формат временных файлов будет использоваться после отключения режима совместимости. В режиме совместимости с версией 8.3.12 поведение не изменилось.

Фоновики.
Реализована возможность ожидать завершение работы одного или нескольких фоновых заданий в течение заданного промежутка времени. Реализован метод ОжидатьЗавершенияВыполнения() для объектов Фо новоеЗадание и МенеджерФоновыхЗаданий . Метод ОжидатьЗавершения() считается устаревшим и не рекомендуется к использованию. Рекомендуется выполнить анализ прикладного решения и изменить алгоритмы работы с фоновыми заданиями.
Оптимизирован запуск и ожидание завершения фоновых заданий

Старт клиента.
Реализована возможность отключать отображение заставки при старте клиентского приложения. Реализован параметр командной строки запуска клиентского приложения DisableSplash . Параметр доступен для тонкого клиента, толстого клиента и веб-клиента.

Оптимизирована и ускорена отрисовка заголовков страниц (закладок) при работе в веб-клиенте.

Обновление используемых библиотек

  • Библиотека LibEtPan обновлена до версии 1.8.
  • Библиотека WebSocket обновлена до версии 0.7.0.
  • Драйвер Micosoft JDBC Driver for SQL Server обновлен до версии 6.2.
Рубрика: ,

Библиотека curl обновлена до версии 7.57.0.
Библиотека OpenSSL обновлена до версии 1.1.0h

Улучшено обновление полнотекстового поиска: Реализована возможность управлять количеством фоновых заданий, выполняющих обновление индекса полнотекстового поиска при работе в клиент-серверном варианте информационной базы. Управление размещением фоновых заданий обновления индекса полнотекстового поиска может выполняться с помощью требований назначения функциональности.
Для объекта МенеджерПолнотекстовогоПоиска реализованы методы УстановитьКоличествоЗаданийИндексирования() и ПолучитьКоличествоЗаданийИндексирования().

Для события технологического журнала FTEXTUpd реализованы свойства MinDataId, MemoryUsed, BackgroundJobCreated, JobCanceledByLoadLimit, TotalJobsCount, FailedJobsCount.

Улучшена диагностика кластера: В свойствах сеанса и соединения реализованы значения, показывающие время, которое затрачено на выполнение вызовов сервисов кластера от имени сеанса или соединения. Данные значения реализованы для всех средств администрирования: консоль кластера, COM-соединение, интерфейс администрирования из языка Java, сервер администрирования.
Для объектов IInfoBaseConnectionInfo и ISessionInfo реализованы свойства:

durationCurrentService — текущее время работы сервиса кластера;
CurrentServiceName — имя исполняемого сервиса;
durationLast5MinService — время работы сервисов кластера за последние 5 минут;
durationAllService — время работы сервисов кластера с начала сеанса или соединения.
Аналогичные свойства реализованы в консоли кластера для списка сеансов, списка соединений и диалога свойств соединения.

Для утилиты командной строки (rac) кластера серверов реализованы параметры duration-current-service, current-service-name, duration-last-5min-service и duration-all-service команд connection list и session list.

Linux: Для работы клиентского приложения под управлением ОС Linux требуется установленная библиотека webkitgtk-3.0 версии 1.4.3 и старше.

Реализована поддержка СУБД Microsoft SQL Server 2017

Реализована возможность использования внешних провайдеров для выполнения OpenID-аутентификации.

Рубрика: , | Метки:

Новый функционал «Система взаимодействия»

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

.

Событие предназначено для расследования событий, связанных с ошибками проверки действительности сертификатов средствами Windows API.Событие формируется только при работе под управлением ОС Windows.

Стало возможно запускать более одного сеанса работы с веб-клиентом из одного веб-браузера.

Повышена скорость работы поиска по началу строки в языке запросов при работе с СУБД PostgreSQL.

При работе с СУБД PostgreSQL реализовано преобразование операции языка запросов ПОДОБНО `ТЕКСТ%` в более оптимальную операцию SQL-запроса.В режиме совместимости с версией 8.3.10 поведение не изменилось.

Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов.

Ускорена работа с временными таблицами, при использовании СУБД Microsoft SQL Server

следующих версий:

  • 2012, версия 11.0.5548.0 и старше.
  • 2014, версия 12.0.2430.0 и старше.
  • 2016.

Повышена скорость работы сервера «1С:Предприятия» в том случае, когда одновременно проводятся документы, содержащие большое количество (десятки тысяч) строк.

Оптимизирована работа с большими временными таблицами под управлением СУБД PostgreSQL.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

Уточнение отображения в линуксе

При работе под управлением ОС Linux, параметр рабочего процесса Занято памяти , вычисляется на основании значения VmRSS (resident set size). Значение параметра Занято памяти стало меньше в абсолютном выражении и более точно соответствует реальности.Рекомендуется провести переоценку параметров перезапуска рабочих процессов в свойствах рабочего сервера.

Добавлен платформенный вариант версионирования данных (для аудита) https://wonderland.v8.1c.ru/blog/istoriya-dannykh/

Рубрика: , | Метки: ,

В технологическом журнале реализовано отражение событий, связанных с:

  • получением и освобождением лицензий (как программных, так и ключей HASP);
  • получением лицензий на базовые версии;
  • регулярным мониторингом соответствия реального оборудования и списка оборудования, зафиксированного в лицензии.

Реализовано событие технологического журнала .

Событие технологического журнала предоставляет возможность анализа только технологических аспектов работы с ключами HASP (вызовы интерфейса работы с HASP), не предоставляя возможности отслеживать получение и освобождение лицензий, получаемых с ключей HASP.

Реализовано журналирование событий, возникающих при первом соединении сервера «1С:Предприятия» с СУБД Microsoft SQL Server, в технологическом журнале. Журналирование выполняется с помощью события .

В документации данное изменение описано и .

Изменен подход к хранению истории исполнения фоновых и регламентных заданий. В клиент-серверном варианте история хранится в разрезе информационных баз. Для каждой информационной базы хранится история:

  • до 1 000 фоновых заданий, созданных из встроенного языка;
  • до 1 000 регламентных заданий;
  • до 1 000 системных фоновых заданий (формируемых самой системой).

Для каждого задания (фонового, системного фонового и регламентного) будет предприниматься попытка хранить информацию минимум о трех последних запусках. Это количество (три запуска) будет уменьшаться в том случае, если превышен лимит в 1 000 записей на тот или иной вид заданий.

Рубрика: , | Метки: , Рубрика: , | Метки: Рубрика: , | Метки: , Рубрика: ,

Реализована возможность использования логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ).

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

В технологическом журнале, в событияхSCALL и CALL, реализованы новые поляIName и MName , которые содержат дополнительную информацию о внутренних вызовах системы. Информация может использоваться специалистами фирмы «1С» при разборе обращений, направляемых в службу поддержки.

Реализовано отражение в технологическом журнале операций обновления индекса полнотекстового поиска. Реализованы события технологического журнала FTEXTCheck и FTEXTUpd. Реализован элемент технологического журнала ftextupd.

На большом количестве пользователей он может оказаться хуже старого режим работы. Чтобы вернуть старый режим записи — для этого (при остановленном сервере 1С):

Найдите в папке базы (…\srvinfo\reg_\) папку журнала регистрации (1Cv8Log),

в папке 1Cv8Log создать пустой файл 1Cv8.lgf.

Повторите эти шаги для каждой базы.

Для снижения нагрузки полезно уменьшать детализацию логирования ТЖ (например, оставить только ошибки)
Можно использовать для хранения журнала регистрации

Неудача нового формата для крупных масштабов признана 1С фактом с версии 8.3.12 возможности интерактивно выбирать формат журнала регистрации (т.е. опытные люди выбирают старый формат).

Рубрика:
  1. Платформа 8.2. Архитектура- клиент-сервер. Задача: нужно чтобы сервер вызвал определенную процедуру на определенном клиенте, подключенном к серверу.
    Возможно-ли это реализовать и как?
    (Это что-то сродни принципу работы ICQ и тому подобного софта, когда не обработчик ожидания опрашивает периодически сервер, а сервер сам вызывает обработчик события на клиенте).
  2. С сервера невозможно вызвать клиента, можно только с клиента вызвать сервер, после выполнения "серверного" кода, управление возвращается обратно на клиента.

    Или изложите мысль более понятней, для чего нужно и какая цель приследуется.
  3. С сервера невозможно вызвать клиента, можно только с клиента вызвать сервер, после выполнения "серверного" кода, управление возвращается обратно на клиента.
    Извините, такая уж архитектура, и не понятно для чего с сервера вызывать клиента. Разбиритесь с архитектурой 8.2.
    Или изложите мысль более понятней, для чего нужно и какая цель приследуется.

    Нажмите, чтобы раскрыть...

    Задача состоит в том, чтобы реализовать механизм уведомлений пользователей о наступлении определенных событий. К примеру менеджер создает заявку на оплату счета или счет. Бухгалтер (находящийся далеко от менеджера) разносит банк. И когда бухгалтер проводит платежку на оплату счета менеджера- менеджеру приходит сообщение (выскакивает окошко) о том, что счет проплачен (как к примеру в ICQ и др. интернет-мессенджерах). Реализовать это можно 2-мя путями:
    1) через обработку ожидания, когда клиент "тыкается" на сервер через определенный интервал времени;
    2) когда клиент просто слушает сервер и когда от сервера приходит сообщение, на клиенте отрабатывает определенная процедура.
    Если с ситемой работает пару-тройка клиентов, то впринципе 1-й вариант решения не вызовет больших проблем. Проблемы начинают возникать когда число клиентов возрастает до нескольких сотен, а ингда даже и несколько десятков могут конкретно забить траффик и загрузить сервер. Режим работы, когда клиент подписывается на список событий на сервере и дальше переходит в режим "прослушки" уменьшает бесполезный траффик в разы и не грузит сервер бесполезными запросами. К примеру зачем периодически выполнять обновление формы списка, если в нем не происходило ни каких изменений? Зачем периодически опрашивать какой-нибудь регистр сведений или задачу, когда в нем ничего не менялось? Менялось или нет знает только сервер. По этому логично чтобы не клиент посылал каждые 5 секунд на сервер запрос и получал один и тот-же ответ, а сервер при подписке на событие (к примеру "при записи" для задачи) вызывал обработку этого события на "заинтересованных" клиентах. Сейчас события обрабатываются только на тех клиентах, которые непосредственно инициировали это событие, а хотелось-бы чтобы событие обрабатывалось еще и на других клиентах (только другим обработчиком).
    Такой принцип работы браузеров обеспечивает технология WebSocket, которая уже в прошлом году стандартизирована (http://www.rfc-editor.org/info/rfc6455) и поддерживается 4-мя браузерами (кроме Internet Explorer). За этой технологией- будущее.

  4. 800 пользователей. Полет стабильный и нормальный. Все зависит от того, как выбирать нужные данные Траффик, кстати, минимальный.

    За тем, что бы не сервер следил за тем, какие сейчас отборы стоят у пользователей в списке, например.
    Также затем, что если пользователю нет нужды обновлять список ->

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

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

    Нажмите, чтобы раскрыть...

    1С является УЧЕТНОЙ, а не биллинговой системой. Ей такое не требуется. Поэтому задача о 5 сек решается иными способами (если она вообще нужна).

  5. Ну про оповещение по e-mail вы вот чего то даже не сказали - а ведь просто организуется, и штатными средствами.
    Ну и собстна можно же к 1Ске прикрутить ICQшник (гуглим либы, курим маны, катаем код) - но IMHO гемор не стоит свеч.

    Но есть и другой способ.



    (б) просто сидит, и слушает выделенный порт (на порт он ждет пакеты данных)
    2) В 1С, в обработке при записи документа пишем код, который анализирует является ли это первая запись, и менялось ли что то существенно с момента последней записи (а то бухи могут документ просто перепроводить, и каждый раз манагеру по этому случаю стент приходить веселый месыдж) и если это новый документ, или он изменен существенно (сумма, плательщик, назначение) то:

    Ну как то так.


    В обработке записи платежных документов пишем код, который при необходимости (дабы при перепроведении старого дока манагера не тревожить) помещает в сторонюю БД

  6. 800 пользователей. Полет стабильный и нормальный. Все зависит от того, как выбирать нужные данные Траффик, кстати, минимальный.

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

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

    Серверов может быть много. В части управляемого приложения - постоянной связи с сервером нет. Ваш запрос может обработаь процесс на другом сервере в кластере.
    Зачем кластеру (на котором может работать тысячи пользователей)помнить все настройки всех пользователей? Что бы память засрать окончательно?
    Кластер и так для каждого коннекта помнит все открытые формы, иначе невозможно было-бы "поднять" сеанс в случае обрыва соединения. А помнить кластеру все это совершенно не обязательно. Можно просто подписки на события сохранять в специальной служебной таблице базы.

    1С является УЧЕТНОЙ, а не биллинговой системой. Ей такое не требуется. Поэтому задача о 5 сек решается иными способами (если она вообще нужна).

    Нажмите, чтобы раскрыть...

    А что, в учетной системе обеспечение актуальности данных является 105-м делом?! К примеру в крупной торговой компании где в системе сидит пару сотен менеджеров не надо, чтобы они видели актуальные остатки, цены товаров? Если этого не будет, то менеджеры по телефону будут обещать товары, которые уже другой менеджер продал , называть устаревшие цены и т.д. А включив периодическое обновление формы списка прайса получаем бесполезную загрузку сервера и значительное увеличение бесполезного трафика.
  7. А менеджеры настолько тупые что не могут сами обновить форму???????????
  8. А в преимущестово этого метода? Только в переносе нагрузки с сервера 1С на почтовый сервер? Ведь все равно клиенту придется периодически опрашивать сервер.
    В чем разница между письмом и телеграммой? Телеграммы раньше разносили почтальоны и вручали лично в руки. Телеграммы-молнии вообще разносили сразу после поступления на почтовое отделение. А за письмом клиенту надо периодически заглядывать в почтовый ящик. В течение суток к примеру приходит 2 письма, а клиент заглядывает в ящик каждые 10 минут. Их всех "заглядываний" только 2 успешных, а остальные бесполезны. А вот с телеграммой все идеально. Клиент занимается своей работой, а когда почтальон приносит телеграмму, он прерывается и получает ее, не тратя время на бесполезную беготню.
    Мне не ICQшник в 1С нужен, я про принцип работы ICQ писал.

    Но есть и другой способ.

    1) Пишем свой простенький клиент. Который обеспечивает либо:
    (а) регулярное обчитывание базы данных (сторонней, например) на наличие записей в таблице с признаком "IsNew_Blead"

    Нажмите, чтобы раскрыть...

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

    2) В 1С, в обработке при записи документа пишем код, который анализирует является ли это первая запись, и менялось ли что то существенно с момента последней записи (а то бухи могут документ просто перепроводить, и каждый раз манагеру по этому случаю стент приходить веселый месыдж) и если это новый документ, или он изменен существенно (сумма, плательщик, назначение) то:
    Для варианта А - создаем в отдельной (а можно и не в отдельной) в нашей таблице запись, с той самой пометкой IsNew_Blead
    Дла варианта Б - стартуем ВКшку (да хоть бы и тупо EXEшничек с параметрами командной строки), которая инициализирует "пинатель" на тот самый выделенный порт.

    Ну как то так.

    Но EMAIL - имхо, проще, и не требует написания дополнительных костылей.
    В обработке записи платежных документов пишем код, который при необходимости (дабы при перепроведении старого дока манагера не тревожить) помещает в сторонюю БД

    Нажмите, чтобы раскрыть...

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

  9. Конечно смогут! Более того, они догадаются, что если в настройках списка формы поставить галку "Обновлять автоматически каждые" и период 5 секунд, то можно на кнопку "Обновить" и не жать. Только на сколько тогда скакнет нагрузка на кластер (сервер) и увеличиться бестолковый трафик по сети от 200 клиентов?!
    Совсем другое дело когда на сервере отрабатывает обработчик "ПриЗаписи" и из него вызывается оповещение нужных клиентов, а клиенты уже формируют запросы и обновляют свои формы. В этом случае всплески трафика и запросов к серверу будут не когда попало, а только когда это действительно необходимо.
  10. А вы представляете если все 200 манагеров будут поочередно, проводить, распроводить, записывать документы??????
  11. У вас сильно эти 200 манагеров своими "бугагашками" по мылу ложат сеть?

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

  12. А попробуйте прописать всем клиентам вызов процедуры, формирующей запрос к примеру по регистру сведений, в который будут прописываться уведомления или по задачам пользователя. И чтобы эта процедура обработчиком ожидания вызывалась хоты-бы каждую минуту. Как "подсядет" сервер и сеть?

    Нажмите, чтобы раскрыть...

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

    Нажмите, чтобы раскрыть...

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

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

    Нажмите, чтобы раскрыть...

    Уточните, чем отличается запрос к базе сервером (для получения подписок) от запроса со стороны клиента? Это одно и тоже Что и с самого начала Вам говорили.




    Отсюда вывод - остаток НЕ имеет актуальности после его прочтения.

  13. Вы слышали когда-нибудь что-нибудь об оптимизации работы приложений? К примеру зайдите на сайт http://www.gilev.ru и посмотрите как работает типовая до и после оптимизации.
    Я как раз и веду разговор что методика "тыкания" клиентов в сервер, по сравнению с методикой оповещения сервером нужных клиентов, является жутко не оптимальной. А если есть неоптимальность в приложении, то это обязательно "вылезет боком" при увеличении нагрузки на систему.

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

  14. У вас сильно эти 200 манагеров своими "бугагашками" по мылу ложат сеть?
    Если сильно - то дрянь у Вас, а не сетка.
    Там трафика то - тьфу. Чего на пустом месте изобретать лесапеды?

    Вот когда возникнет "да, сетка еле ползает" и при этом вы будете уверены, что это из за этого авто-опроса раз в 5 секунд - вот тогда и станете репу чесать.

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

    Нажмите, чтобы раскрыть...

    А помните, что платформа 8.2 еще может в режиме тонкого клиента, а еще и на медленных соединениях работать?! А теперь подумайте, если на медленном соединении исключить часть бестолкового трафика, быстрее будет клиент бегать?

  15. А помните, что платформа 8.2 еще может в режиме тонкого клиента, а еще и на медленных соединениях работать?! А теперь подумайте, если на медленном соединении исключить часть бестолкового трафика, быстрее будет клиент бегать?

    Нажмите, чтобы раскрыть...

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

    Не путайте методы Славы для конфигурации со своими предложениями о платформе. Как раз-таки Слава и делает процесс обмена сервер-клиент минимальным.

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

    Нажмите, чтобы раскрыть...

    Еще раз: приведите паттерн. На общий вопрос вы получили общий ответ. Когда будет видна конкретная задача - уже имеет смысл обсуждать.
    Минусы дерганья с сервера клиента в двух словах я уже описал.

  16. Посмотрите типовые - там так и сделано. К слову, у нас в корпоративной базе - тоже так.
    Ничего, все живы и здоровы. Тут вопрос в том, как построить эти данные. Если фигачить от балды - я на пустой базе положу Вам сервер, не шибко напрягаясь.

    Нажмите, чтобы раскрыть...

    Типовые так написаны потому, что:
    1) так написана платформа и за ее возможности не перепрыгнеш, не используя ВК.
    2) в типовых иногда пишут такой код, за который никогда в жизни 1С не зачел-бы экзамен.
    Никакой геморой не предполагается и не полностью все наоборот. Клиент открывает соединение, а дальше понятие "клиент" и "сервер" стирается. Инициирует передачу тот, кому это надо сделать. Прочитайте пожалуйста http://ru.wikipedia.org/wiki/WebSocket. Неужели это "чайники" придумали?

    Поясню еще одно: что должно произойти, когда у пользователя во весь экран открыт документ и пришло оповещение с сервера, что надо бы этот документ обновить?
    Уткнетесь в то, что надо будет такое событие отрабатывать, думать о том, что пользователь изменил и как все это связать в одно. Замудохаетесь, проще говоря.
    И еще: случай в вакууме рассматривать бесполезно. Нужна конкретика.

    Нажмите, чтобы раскрыть...

    В курсе, что если для события не назначена процедура обработки, то это событие и не обрабатывается? Это уже разработчику решать, надо или нет обновлять форму документа, если его кто-то изменил. А думать о том, что пользователь изменил вообще не надо! Попробуйте открыть один и тот-же документ на разных клиентах и изменить реквизит на одном из них. Что происходит? Правильно, запись автоматом блокируется! И до момента отмена блокировки другой клиент не сможет ничего записать в базу. А после записи, другой клиент если и наменял чего, то тоже не сможет записать, т.к. изменилась версия данных.
    Ну это вообще "глубочайшее" понимание 3-х звенной структуры 1С:Предприятия 8.2.
    Разница в том, что клиент не работает с базой, а работает с сервером приложений 1С, а сервер приложений работает с базой. Для серьезных систем скорость обмена между клиентом- сервером 1С и сервером 1С- сервером SQL на несколько порядков различаются. Для того и придумали сервер приложений, чтобы уменьшить объем передаваемых данных от сервера- клиенту. По этому скорость выполнения запроса и обработка результата сервером приложений в разы или даже на порядки выше чем если тоже самое будет делать клиент.

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

    Подумайте, что произойдет по Вашему сценарию на 1000 пользователей.
    Форма остатка у Вас будет обновляться бесконечно (количество будет менять постоянно - ибо 1000 пользвоателей!)
    Отсюда вывод - остаток НЕ имеет актуальности после его прочтения.

    Нажмите, чтобы раскрыть...

    Все зависит от конкретной системы. Если частота записи возрастает, то можно оповещать клиентов и реже. Все это можно "разрулить" разработчику, если-бы платформа 1С позволяла реализовать эту методику. Протокол WebSocket не исключает использование протокола http, а дополняет его. Разработчику решать, использовать метод "тыкания" клиента в сервер или использовать оповещение сервером клиентов. А пока платформа дает только единственный вариант работы приложения.

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

    Далее. Какой вызов сервера обработчика на клиенте??? Кто такой клиент для сервера - да нет ни кто, и зовут его никак, ни родины ни флага, сегодня он есть - завтра нет. Или, послать оповещение Васе Пупкину, правда он тормоз, и до него все доходит с третьего раза, пошлю-ка я ему три уведомления, вдруг проснется, а Машеньке - она умница все понимает с полу-слова, так что пошлю я ей половину оповещения, пусть додумывает сама, взрослая уже.
    Так что, что вы тут говорите - это пустая вода, в 1С тоже не практиканты сидят, знают за что деньги получают.)
    По делу. Вас никогда не напрягало всплывающее сообщение аськи, при просмотре кинофильма??? Хотя и это можно отключить, но тогда как я узнаю когда именно нужный мне контакт появится в сети? Ну это лирика, так сказать.

    Нажмите, чтобы раскрыть...

    Провожу аналогию: web-сервер и браузеры клиентов. Кого больше? WEB-сервера+SQL (что часто-густо) не такое-же хранилище? Физически WEB-сервера и SQL-сервера также могут быть объединены в кластер. Что, на всем этом не реализуется протокол WebSocket, реализующий реальную дуплексную связь между клиентом и сервером (где не только клиент, но и сервер инициирует передачу). А по поводу напряга выскакивающего окошка- так если я не хочу принимать сообщения, я просто ухожу в offline или отключаю выскакивание окошка.

    Далее. Какой вызов сервера обработчика на клиенте??? Кто такой клиент для сервера - да нет ни кто, и зовут его никак, ни родины ни флага, сегодня он есть - завтра нет. Или, послать оповещение Васе Пупкину, правда он тормоз, и до него все доходит с третьего раза, пошлю-ка я ему три уведомления, вдруг проснется, а Машеньке - она умница все понимает с полу-слова, так что пошлю я ей половину оповещения, пусть додумывает сама, взрослая уже.
    Так что, что вы тут говорите - это пустая вода, в 1С тоже не практиканты сидят, знают за что деньги получают.
    Все что вы говорите, можно сделать и на клиенте, причем с минимальными затратами.
    Не вижу смысла дискусировать дальше. Тему предлагаю закрыть.

    Нажмите, чтобы раскрыть...

    А как думаете, в Google сидят практиканты которые придумали протокол WebSocket?! Если-бы ета идеология была утопической, нерациональной и т.п., то WebSocket (описан в документе RFC 6455) не получил-бы от IETF статус «предложенного стандарта». Следующий статус- «черновой стандарт» имеет подавляющее большинство стандартов, используемых в Интернет.
    А что касается клиента- то без клиента как раз сервер никто и зовут его никак; совершенно бесполезное скопление программно-аппаратных средств. Клиент для сервера все-равно что покупатель для продавца. Сервер обеспечивает клиента необходимыми данными, сервер для клиента формирует управляемые формы, вообще сервер существует ради клиента, а не наоборот! В версии 8.2 сервер даже запоминает сеанс пользователя. Читаем: http://v8.1c.ru/overview/Term_000000805.htm#1 раздел "Устойчивость к обрыву канала связи".
    Так кто для кого существует?

  18. Может меня не совсем правильно понимают? Я предлагаю не поменять методику обмена между клиентами и сервером с запрос-ответ на дуплексную, я предлагаю добавить механизм дуплексного оповещения одних клиентов другими, о совершении другими клиентами определенных действий через сервер. Этот механизм разработчики могут использовать по своему усмотрению. Как к примеру захотел разработчик вместо запроса обойти элементы справочника через объектную модель- пожалуйста. И на маленьких справочниках этот метод иногда значительно увеличивает скорость работы.
    А так программно можно только получить список всех подключений к базе и вызвать отключение от базы какого-либо пользователя (при наличии на это прав). А вот послать уведомление пользователю и чтобы при этом сработал вызов определенной процедуры- нельзя.

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.11.2867.

Во время длительной серверной операции пользователь всегда хочет видеть на клиенте ход её выполнения. Для того чтобы оценить, сколько времени осталось до её завершения, или насколько быстро она выполняется. Чтобы это реализовать, необходимо каким-то образом передавать информацию с сервера на клиента. Но и раньше, и сейчас взаимодействие между клиентской и серверной частью 1С:Предприятия происходит только по инициативе клиента. Сервер 1С:Предприятия сам, по своему желанию, не может вызвать какое-либо клиентское приложение и передать ему информацию.