По какому протоколу работает 1с с сервера

Обновлено: 19.05.2024

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

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

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

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

Начнем с клиентов, текущая версия платформы (8.2) предусматривает использование трех типов клиентов. Разберем их подробнее.

Толстый клиент

Это классическое клиентское приложение 1С, до выхода платформы 8.2 он был единственно доступным видом клиента. Схема работы толстого клиента следующая: клиентское приложение запрашивает данные у сервера 1С, то в свою очередь запрашивает их из БД и предает обратно клиенту, на котором и производится их обработка. Как можно заметить, данная схема неоптимальна: сервер 1С по сути является всего лишь прослойкой между клиентом и БД, все вычисления происходят на клиенте. Это накладывает повышенные требования на клиентские ПК, т.к. вычислительные мощности сервера не используются. Стоит четко понимать, что в режиме толстого клиента вы не получите увеличения быстродейстивия от перехода к клиент-серверной версии, возможно даже наоборот.

Тонкий клиент

Его можно назвать основным видом клиентского приложения для платформы 8.2, в теории, на практике не все так гладко и мы еще к этому вернемся. Схема его работы кардинально иная: клиент запрашивает данные у сервера 1С, тот получает их из БД, обрабатывает и отдает клиенту результат вычислений. Основная вычислительная нагрузка при этом ложится на сервер, поэтому особых требований к клиентским ПК и каналу от клиента к серверу не предъявляется.

Веб-клиент

Теперь о ложке дегтя в бочке меда. Для нормальной работы в режиме тонкого и веб-клиентов конфигурация должна работать в режиме управляемого приложения и поддерживать все функции в данном режиме. Режим управляемого приложения является основным для платформы 8.2 и довольно радикально отличается от того, что было раньше, в том числе и внешне. Визуально управляемое приложение можно отличить по новому интерфейсу, отличительными чертами которого являются вкладки и гиперссылки:

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

На сегодня в режиме управляемого приложения работает лишь часть типовых конфигураций, такие как: Управление небольшой фирмой, Управление торговлей 11, Розница 2 и Зарплата и управление персоналом. Эти решения могут использовать все преимущества новой платформы. Бухгалтерия предприятия 2.0 не использует режим управляемого приложения и в тонком и веб-клиентах работать не будет, это же относится и ко многим сторонним решениям, таким как "Камин" и т.п.

Выводы

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

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

Кластер серверов 1С

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

Также система не накладывает никаких требований к платформам. Вы можете совместно использовать как Windows так и Linux сервера, в качестве веб-сервера можно использовать Apache и IIS, из СУБД поддерживаются PostgreSQL, MS SQL Server, IBM DB2 и Oracle. Поэтому никто не мешает вам создать схему, в которой сервер 1С работающий на платформе Linux будет работать совместно с сервером БД под управлением Windows Server и IIS и наоборот. Кроме того вы можете использовать несколько серверов СУБД (как и веб-серверов) располагая разные базы на разных серверах.

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

И наконец самое интересное: кластер серверов 1С Предприятия. Да, именно так, не одиночный сервер, а кластер серверов. Обычно здесь и начинаются непонятки, особенно если сервер один. Однако все встает на свои места, если принять во внимание, что понятие кластера серверов в первую очередь логическое, однако данный подход легко позволяет масштабировать схему повышая ее производительность или отказоустойчивость.

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

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

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

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

При интеграции 1С:Предприятие с другими системами возможны случаи когда работа возможна только по протоколам TCP\IP или UDP. Платформа 1С не предоставляет механизмов для прямого взаимодействия с этими протоколами, что крайне неудобно, но, тем не менее, не невозможно.
Для работы с этими протоколами в среде Windows предназначена технология Windows Sockets.
Реализует эту технологию библиотека Mswinsock.dll (Mswinsock.ocx).

В качестве транслятора в протоколы TCP\IP или UDP данных из (в) 1С:Предприятие можно использовать ActiveX компоненту, входящую в состав библиотеки Mswinsock.dll.

Эта библиотека входит в состав пакета Visual Basic который можно установить вместе с пакетом программ MS Office. Ну или найти в Интернете.

Её полноценное использование в среде 1С:Предприятие возможно только в качестве ActiveX элемента на форме.

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

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

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

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

Свойства.

Из дополнительных свойств стоит отдельно выделить свойство "State" в это свойство содержит числовое значение текущего состояния компоненты - Статус.

Список возможных значений

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

Свойство LocalPort числовой параметр, указывающий, какой порт будем прослушивать функцией Listen().

Свойства RemotePort и RemoteHost - это параметры, указывающие по какому адресу (IP или DNS) и на какой порт совершать подключение к серверу функцией Connect().

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

Доступные события.

Error - Событие возникает при возникновении какой-либо ошибки.

Процедура WinSocketError ( Элемент , Number , Description , Scode , Source , HelpFile , HelpContext , CancelDisplay )

В параметрах события возвращается

Number - цифровой код возникшей ошибки,
Description - текстовое описание ошибки,
Scode - код ошибки в типе Long (HRESULT) SCODE
Source - описание источника ошибки,
HelpFile - ссылка на Файл справки
HelpContext - контекст файла справки
CancelDisplay - флаг отмены отображения стандартного окна об ошибке. По умолчанию значение - Истина. Окно не выводится.

DataArrival - возникает при поступлении данных.

Процедура WinSocketDataArrival ( Элемент , bytesTotal )

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

Connect - событие возникает при успешном подключении к серверу. Возникает только на стороне клиента.

Процедура WinSocketConnect ( Элемент )

Сообщить ( "Покдлючение к " + Элемент . RemoteHost + " успешно." );

Это событие не имеет собственных параметров.можно работать только с параметрами самой компоненты.

ConnectionRequest - серверное событие, возникает при поступлении запроса на подключение.

Процедура WinSocketConnectionRequest ( Элемент , requestID )

Сообщить ( "Запрос подключения" );

Если НЕ WinSocket . State = 0 Тогда
WinSocket . Close ()
КонецЕсли;

WinSocket . Accept ( requestID );

Сообщить ( "Приконнектился " + WinSocket . RemoteHostIP );

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

Тут же можем получить IP-адрес подключаемого клиента из параметра RemoteHostIP.

Теперь, после установления соединения, можем передавать данные в обе стороны.

Close - Событие, возникающее при вызове метода Close() т.е. при закрытии компоненты.

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

Процедура WinSocketSendProgress ( Элемент , bytesSent , bytesRemaining )

Сообщить ( "Байт отправленно - " + bytesSent + "/ байт осталось - " + bytesRemaining );

Из картинки видно, что вызов процедуры произошел только один раз.

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

Читайте также: