Ragent exe что это
Как быстро обновить много серверов 1С
В основном проблема обновления платформы 1С стоит для клиентской части. Клиентских компьютеров может быть десятки и сотни, в то время как серверов на порядки меньше. У нас проблема обновления клиентских машин не стоит, клиенты запускаются на VDI, а там обновление сводится к установке на одной виртуальной машине и ее клонировании.
После победы над клиентами хочется разобраться с серверной частью. В интернете есть достаточное количество статей на тему, как обновить платформу 1С на клиентских машинах.
С серверной частью все ПОЧТИ тоже самое. Вот про это ПОЧТИ и хочу рассказать.
У нас для серверов 1С используется Windows, поэтому все, что написано далее относится только к установке 1С на Windows.
Обновление серверной части, состоит из нескольких действий:
Установка платформы 1С на сервере
Регистрация компонентов, таких как COM и консоль администрирования
Обновление пути к компоненте wsisapi.dll в конфигурационных файлах веб-сервера, в нашем случае IIS.
Побеждаем установку сервера
Суть всей установки сводится к запуску 1CEnterprise 8 (x86-64).msi с параметрами, которые есть в документации:
THICKCLIENT – толстый клиент (в том числе позволяет запускать конфигуратор)
THINCLIENT – тонкий клиент для клиент-серверного варианта работы.
THINCLIENTFILE – тонкий клиент с возможностью работы с файловыми информационными базами
SERVER – серверная часть 1С
WEBSERVEREXT – компоненты расширения для веб-сервера
CONFREPOSSERVER – сервер хранилища конфигураций
SERVERCLIENT – компоненты для администрирования кластера серверов
CONVERTER77 – конвертер информационных баз из версии 1С:Предприятия 7.7
LANGUAGES – список языков интерфейса для установки через запятую
То есть, если хотим установить серверную часть 1С, то запуск установки будет выглядеть примерно так:
И вот здесь начинаются проблемы. При установке серверной части происходит регистрация сервиса и его запуск. При этом, такие параметры запуска, как каталог файлов сервера, пользователь под которым будет работать служба сервера указать невозможно. Это приводит к тому, что настроенные в реестре параметры запуска службы сервера будут перезаписаны на значения по умолчанию. Мы попробовали два подхода к устранению этой неприятности:
Подход 1: Не будем регистрировать и запускать сервис
Попробуем отключить регистрацию и запуск сервиса. Регистрацию и запуск сделаем отдельными скриптами. Стандартных параметров запуска недостаточно. Давайте поменяем саму программу установки. Качаем Windows SDK и устанавливаем Orca. Открываем нашего пациента 1CEnterprise 8 (x86-64).msi и, посмотрев на таблицу InstallExecuteSequence, видим, что многие действия, в том числе и запуск сервиса, зависят от параметра INSTALLSRVRASSRVC. Скорее всего его установка в «0» и поможет нам отказаться от регистрации и запуска сервиса. Поиском ищем, где же он устанавливается. Установка значения нашлась в таблице CustomAction в действии customSetSrvrAsService. Меняем Target на 0 и сохраняем наш файл трансформации DoNotRegister.mst.
Добавляем его в команду установки, и все выполняется без регистрации и запуска сервиса.
Далее необходимо только сменить путь к агенту сервера (C:\Program Files\1cv8\8.3.xx.xxxx\bin\ragent.exe) в реестре.
Подход 2: Пусть все будет стерто, настроим заново
Регистрация COM и консоли администрирования
Это самые простые действия. Для регистрации COM Запускаем
regsvr32 /n /i:user «C:\Program Files\1cv8\8.3.xx.xxxx\bin\comcntr.dll» на PowerShell наш скрипт выглядит так:
Для регистрации консоли
regsvr32 /n /i:user «C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll» на PowerShell наш скрипт выглядит так:
Обновление пути к компоненте wsisapi.dll
Данное действие тоже достаточно простое, настройка веб публикации 1С систем сводится созданию в IIS приложения состоящего default.vrd и конфигурированием Handler mappings. С последним возникают тонкости. Настройки могут быть заданы как на уровне приложения, так и на уровне сайта или сервера в целом. Мы пошли по наиболее простому пути. В последних версиях платформы 1С утилита публикации (создания приложений) создает конфигурацию на уровне приложения. Так как публикации рождаются и изменяются регулярно в процессе развития систем, то чтобы не наступить на грабли, что в разных местах у нас разные настройки, решили остановиться на одном варианте. Конфигурационный файл web.config должен быть у каждого приложения. Мы проверили все наши публикации и там, где отсутствовал конфигурационный файл, создали его. Теперь в каждой директории приложения имелся файл web.config и задача свелась к замене версии платформы в строке:
Надеюсь, этот материал оказался полезным для вас. А как вы решаете проблему обновления нескольких серверов 1С? Делитесь вашими know-how в комментариях.
Про кластер серверов 1С
Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс
Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
К желаемому результату мы пришли не сразу.
В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:
Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
1С:Предприятие 8.0
Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
1С:Предприятие 8.1
В следующей версии мы захотели:
Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
1С:Предприятие 8.2
В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
Отказоустойчивость
Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
Механизм работает так. Если клиентский вызов к рабочему процессу по какой-то причине не смог исполниться до конца, то клиентская часть способна, получив ошибку вызова, этот вызов повторить, переустановив соединение с тем же рабочим процессом или с другим. Но повторять вызов можно не всегда; повтор вызова означает, что мы отправили вызов на сервер, а результата не получили. Мы стараемся повторить вызов, при этом при выполнении повторного вызова мы оцениваем, каков результат на сервере был у предшествующего вызова (информация об этом сохраняется на сервере в данных сеанса), потому что если вызов успел там «наследить» (закрыть транзакцию, сохранить сеансовые данные и т.п.) – то просто так повторять его нельзя, это приведет к рассогласованию данных. Если повторять вызов нельзя, клиент получит сообщение о неисправимой ошибке, и клиентское приложение придется перезапустить. Если же вызов «наследить» не успел (а это наиболее частая ситуация, т.к. многие вызовы не меняют данных, например, отчеты, отображение данных на форме и т.п., а те, которые меняют данные – пока транзакция не зафиксирована или пока изменение сеансовых данных не отправлено в менеджер – следов вызов не оставил) — его можно повторить без риска рассогласования данных. Если рабочий процесс упал или произошел обрыв сетевого соединения – такой вызов повторяется, и эта «катастрофа» для клиентского приложения происходит полностью незаметно.
Балансировка нагрузки
Задача балансировки нагрузки в нашем случае звучит так: в систему заходит новый клиент (или уже работающий клиент совершает очередной вызов). Нам надо выбрать, на какой сервер и в какой рабочий процесс направить вызов клиента, чтобы обеспечить клиенту максимальное быстродействие.
Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
Резервирование кластеров
Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
1С:Предприятие 8.3
В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
Три звена отказоустойчивости
Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
В заключение
Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
Как правильно обновить платформу 1С и запустить несколько служб 1С на одном сервере?
Как правильно обновить платформу 1С и запустить несколько служб 1С на одном сервере?
Введение
Как быстро и без проблем установить новую версию платформы 1С и при этом минимизировать прерывание работы пользователей? Как запустить несколько экземпляров сервера 1С на одной машине? Данные вопросы являются распространенным предметом для обсуждения среди администраторов серверов 1С. В общем, ответы на них вы можете найти на сайте ИТС по этой ссылке, а также по этой.
В нашей статье мы хотим выделить самое главное, добавить что-то от себя, а также поделиться опытом, и, что достаточно важно, показать, что данные задачи не являются чем-то сложным и решаются буквально в два счета и даже без танцев с бубном, как многие думают.
Обновление платформы
Так как установка службы 1С на сервер, где ее еще не было, не представляет никаких сложностей и не отличается какими-то особенностями, рассмотрим другую задачу, когда у нас уже есть продуктивный сервер с запущенным сервером приложений, в котором работают пользователи, и нам необходимо обновить на нем версию платформы 1С. Эту задачу можно разбить на два условных этапа: подготовительный этап и этап обновления.
Подготовительный этап
Когда мы убедились, что все в порядке, можем запускать установку платформы 1С на сервере приложений. Если при его установке снять галочку «установить как сервис», можно не останавливать службу 1С, обслуживающую текущую версию платформы 1С и, что очень важно, можно не прерывать работу пользователей.
После этого все компоненты сервера будут установлены, но не будут использоваться.
Этап обновления
После того, как подготовительный этап закончен, необходимо согласовать с пользователями время, когда можно будет прервать их работу на несколько минут. Когда это время настанет, нужно остановить службу 1С и изменить строку запуска службы 1С, а именно путь к исполняемому файлу ragent.exe. Это можно сделать несколькими способами:
В нужный момент кликаем правой кнопкой мыши на экспортированный файл реестра с измененной строкой запуска службы 1С и нажимаем «Слияние». Преимущество данного метода в том, что данный файл мы можем подготовить заранее и выполнить изменение параметров службы 1С в два клика без необходимости «копаться» в реестре.
sc config [имя службы 1С в которой меняем версию платформы 1С] binPath= [строка запуска службы 1С новой версии платформы]
Строку запуска службы 1С новой версии платформы можно получить из строки запуска службы 1С текущей версии платформы, заменив в ней путь до исполняемого файла ragent.exe:
Например, если мы хотим обновить версию платформы с текущей (например, 8.3.7.1873) до 8.3.7.1917, тогда строка запуска текущей версии может выглядеть так:
имя службы 1С, например, следующее:
1C:Enterprise 8.3 Server Agent (x86-64)
тогда скрипт будет выглядеть так:
Установка дополнительной службы 1С
Итак, для того, чтобы использовать несколько экземпляров сервера 1С на одной машине, для обеих версий серверов 1С(если они отличаются) сначала выполняем «Подготовительный этап» из предыдущего пункта.
Далее нам понадобится следующий скрипт:
@echo off
rem %1 — полный номер версии 1С:Предприятия
rem %2 — первые цифры номеров портов
rem %3 — цифра сотого разряда номеров портов
rem %4 — каталог с данными службы 1С
set SrvUserName=
set SrvUserPwd=
set RangePort=%2%301:%2%399
set BasePort=%2%300
set CtrlPort=%2000
set SrvcName=»1C:Enterprise 8.3 Server Agent %CtrlPort%»
set BinPath=»\»C:\Program Files\1cv8\%1\bin\ragent.exe\» /srvc /agent /regport %BasePort% /port %CtrlPort% /range %RangePort% /d \»%
4\» /debug»
set Desctiption=»Агент сервера 1С:Предприятия 8.3. Параметры: %1, %CtrlPort%»
if not exist «%
4″
sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj= %SrvUserName% password= %SrvUserPwd% displayname= %Desctiption% depend= Dnscache/Tcpip/Tcpip6/lanmanworkstation/lanmanserver
| Процесс | Порты |
|---|---|
| ragent | 1540 |
| rmngr | 1541 |
| rphost | 1560:1591 |
К сожалению, такая структура портов не всегда является удобной. Например, если мы захотим использовать несколько кластеров в рамках одной службы 1С, а служб мы при этом используем несколько на одной машине. В этом случае может возникнуть путаница с диапазоном используемых процессами rphost портов. Если, например, процесс ragent одной службы 1С занимает порт 1540, а другой — 1640, для первой создан кластер 1С диапазон портов которого 1560:1591 и мы хотим создать еще один кластер, то диапазон портов для него, по логике, должен быть 1660:1691, но этот диапазон может быть занят (и, скорее всего так и будет) рабочими процессами кластера ragent’а занимающего порт 1640.
Итак, приведенный выше скрипт следует сохранить в командный файл, который назовем register-service.bat. Перед его применением необходимо указать в нем данные реального пользователя (имя и пароль) от имени которого будет работать служба кластера серверов (строки set SrvUserName= и set SrvUserPwd=). Примечание: если в скрипте используются символы кириллицы, командный файл следует сохранять в кодировке OEM 866.
Для регистрации службы выполните из командной строки следующую команду:
register-service [номер версии платформы] [первые цифры номеров портов] [цифра сотого разряда номеров портов] [каталог службы 1С]
Например, если нам необходимо зарегистрировать две службы для двух серверов 1С одинаковой версии 8.3.6.2332, то в командной строке напишем следующее:
register-service 8.3.6.2332 2 1 «C:\Program Files\1cv8\srvinfo_2000
register-service 8.3.6.2332 3 1 «C:\Program Files\1cv8\srvinfo_3000
Типичные ошибки и возможные проблемы
Помимо этого, необходимо помнить, что по умолчанию 1С регистрирует порт 1541 для менеджера кластера, то есть в параметрах запуска службы 1С можно увидеть:
Это значит, что после установки новой версии платформы при запуске службы по умолчанию всегда будет создан новый кластер и запущен процесс rmngr.exe, даже если он в принципе на сервере нам не нужен, и мы не хотим использовать этот рабочий сервер, как центральный. Также в строке запуска указан диапазон портов rphost для нового кластера:
К сожалению, на данный момент нет возможности управлять созданием локального кластера при первоначальном запуске службы 1С с помощью параметров командной строки службы. Но эту задачу можно решить следующими двумя способами.
Первый и, пожалуй, самый простой — это удалить созданный локальный кластер из консоли кластера 1С:
Второй вариант: для того, чтобы при первоначальном запуске службы 1С новый кластер не создавался, перед её запуском в каталоге служебных файлов данной службы, который указан в строке её запуска после ключа –d, необходимо создать файл с именем 1cv8wsrv.lst следующего содержания:
Мы получим такой же файл при удалении локального кластера, как это описано в первом варианте.
После этого можем запускать данную службу 1С. При старте службы, происходит проверка наличия файла 1cv8wsrv.lst в каталоге служебных файлов новой службы 1С. Из этого файла читаются данные о зарегистрированных кластерах. Если файла нет – создается кластер по умолчанию с параметрами, заданными в строке запуска службы, если файл есть, данные читаются из него и автоматического создания не происходит. Соответственно, в этом случае наличие данного файла подтверждается и новый кластер не создается.
Если новый кластер создать все-таки нужно, то необходимо проверить, что порт в параметре /regport (или порт по умолчанию — 1541, если параметр /regport не указан), при регистрации новой службы не занят. Если этого не сделать, то возможно проявление ситуации, когда две службы будут работать с одним менеджером кластера, если, например, для порта, указанного в строке запуска новой службы (или для порта по умолчанию — 1541, если ключ –regport не указан в строке запуска) уже зарегистрирован менеджер кластера. Причиной этого является то, что при первоначальном старте службы и регистрации порта для менеджера кластера не происходит проверки занят этот порт или нет. Задача по реализации данной проверки известна и будет реализована в следующих версиях платформы.
Еще один параметр строки запуска службы 1С, который стоит рассмотреть, это:
Он отвечает за каталог, в котором будут расположены (или располагаются) служебные файлы службы сервера 1С (в том числе список кластеров). По умолчанию каталог устанавливается следующий:
Также многие забывают указывать ключ в строке запуска, отвечающий за возможность использования приложения в режиме отладки, если он необходим:
Помимо этого, одной из частых ошибок является то, что администратор 1С забывает удалить служебные файлы информационных баз (а именно: индексы полнотекстового поиска и журналы регистрации) из каталога реестра кластера 1С после того, как базы удалены из списка информационных баз кластера 1С. Данная ошибка приводит к тому, что дисковое пространство сервера приложений используется неэффективно.
Каталог реестра кластера выглядит следующим образом:
«C:\Program Files\1cv8\srvinfo\reg_[номер порта менеджера кластера]»
Каталог служебных файлов информационной базы:
«…\srvinfo\reg_****\[UUID информационной базы]»
Например, если номер порта менеджера кластера 1541, то каталог служебных файлов некоторой информационной базы с уникальным идентификатором «0c1bd57c-4a1b-47df-a229-ade9833de359» будет:
Список неиспользуемых баз можно получить, сравнив по уникальному идентификатору список баз в файле «1CV8Clst.lst» (располагается в каталоге реестра кластера) и список баз, для которых существуют каталоги со служебными файлами. Для быстрого получения идентификаторов баз и их имен из файла реестра кластера можно воспользоваться следующим регулярным выражением: «\<(\w<8>\-.*\w<12>)\,\»(.*?)\»\,.*[\\r]*\n+.*\»\,\d+\>».
Заключение
Мы постарались скомпоновать в статье достаточно полную и подробную информацию о том, как правильно и быстро обновить версию платформы 1С. Такая информация может быть полезна на предприятиях, где длительное прерывание работы пользователей может быть достаточно критичным.
Также достаточно важным было для нас описать, как настроить одновременную работу нескольких служб кластера 1С на одной машине. Эта информация может быть полезна тем, кто хочет изолировать несколько кластеров 1С, например, для целей разработки или тестирования или вы используете в работе информационные базы, управляемые разными версиями 1С:Предприятия.
Надеемся, вы сможете с легкостью выполнить нужную вам задачу и продолжите с удовольствием пользоваться продуктами 1С. Ну а если у вас что-то не получится, или вы столкнетесь с какими-то трудностями, обращайтесь к нам, мы обязательно поможем!