Infobase 1c что это
Итак у вас установлено 1С:Предприятие, как определить каким способом или вариантом загружается ваша информационная база (ИБ)?
Если у вас файловый вариант работы то в строке при запуске 1С и при выборе информационной базы (в списке информационных баз) вы увидите: File=”C:\Documents and Settings\Pupkin\Мои документы\Infobase1”. Это папка, где хранится ваша файловая база.
Если вы увидите такую надпись типа Srvr=»192.168.6.1″;Ref=»Infobase1″;, то это означает, что вы работаете в клиент-серверном варианте работы с 1С.
Что означает файловый вариант работы — вы более или менее понимаете.
Клиент-серверный вариант работы предполагает обмен данными через сеть по специальному порту и IP-адресу того компьютера, где установлена база данных.
В случае клиент-серверного варианта работы на компьютере, где установлена база данных работает специальная служба, которую вы можете посмотреть в Панели управления, пункт “Администрирование” и выбрать оснастку “Службы”; в списке служб вы увидите примерно следующее (зависит от версии 1С) — “Агент сервера 1С:Предприятие 8.хх” или к примеру вот такую службу “1C:Enterprise 8.2 Server Agent:”.
В случае работы с клиент-серверным вариантом, очень полезна оснастка, которая находится в меню Пуск->Все программы(программы)->1С Предприятие 8.х->Дополнительно->Администрирование серверов 1С Предприятия.
Что нам дает данная оснастка в плане работы с пользователями и выгрузкой ИБ?
1. Здесь мы можем завершать работу пользователей
2. Здесь мы можем устанавливать блокировку, запрещающую вход пользователям (на тот случай если нам необходим монопольный доступ к информационной базе)
Оснастка может запрашивать пароль, но какой?
Имя пользователя и пароль (для вас как для Администратора БД) — укажите ваше Имя пользователя и пароль, который вы используете для входа в 1С:Предприятие.
Итак, что мы здесь видим. Видим сервер 1С Предприятия (My_1C) и информационную базу (порт по умолчанию 1541) — My_UPP. В правой части окна видим возможность выбрать -> Сеансы, Блокировки, Соединения.
Сейчас нас интересует ветка с информационными базами, — нажмите правую клавишу мыши на выбранной ИБ, и воспользуйтесь командой “Свойства”, Контекстного меню.
Для того, чтобы запретить пользователям входить и работать с информационной базой необходимо поставить галочку — “Блокировка начала сеансов включена”.
Обратите внимание на Даты начала блокировки и конца блокировки. Начиная с даты и времени начала блокировки и даты и времени окончания блокировки — база будет находиться в монопольном режиме.
До тех, пор пока вы не снимите галочку, никто не может войти и работать с информационной базой, но … Для того, чтобы вы могли сами заходить в ИБ(при помощи командной строки), предусмотрите Код разрешения.
Блокировка регламентных заданий включена — эта блокировка необходима для того, чтобы не разрешать 1С запускать различные регламентные задания в фоновом режиме. Регламентное задание — это какая-либо операция, запускающаяся по расписанию, иногда для того чтобы обновить конфигурацию — мешают регламентные задания, которые запускаются как назло в те моменты, когда вы работает с базой — можете на время воспользоваться указанной возможностью.
Часто бывает такая ситуация, что сервер 1С:Предприятия установлен на одном компьютере (какой-либо главный сервер, как в нашем случае My_1C), а “рулить” вы хотите сервером со своего локального компьютера. (Также возможна ситуация что у вас несколько серверов, а управлять вы хотите этими серверами с локальной оснастки вашего компьютера).
Сделаем следующее на локальной машине откроем оснастку “Администрирование серверов 1С Предприятия” (путь Пуск->Все программы (Программы)->1С_Предприятие 8.х->Дополнительно->Администрирование серверов 1С Предприятия). Если вдруг на локальной машине у вас не установлен этот компонент, то вы его не увидите — идете в Панель управления ->Установка и удаление программ и ищете строку с установкой 1С Предприятия, и изменяете настройку компонентов, добавляя оснастку “Администрирование сервера”
Итак, нашли, выполнили, посмотрели. Идём далее.
В оснастке мы видим пустую строку не включающую в себя ничего, что-то типа Console Root-> Central 1C:Entreprise 8.2 servers. Ставим курсор на эту строку, нажимаем правую клавишу мыши и выбираем команду Создать->Центральный сервер 1С Предприятия 8.2.
Вписываем имя нашего сервера, находящегося в сети, нажимаем “ОК”. и всё — мы имеем возможность работать с локального компьютера и управлять нашим сервером 1С.
В первой части статьи был рассмотрен собственно Автономный сервер – приложение ibsrv, его преимущества, ограничения, показания к использованию.
Перейдем ко второй части, представляющей для кого-то, возможно, даже больший интерес. В первую очередь, думаю, это должно заинтересовать адептов CI-CD.
Утилита администрирования – ibcmd
Утилита администрирования на текущий момент предоставляет два режима работы
- Server – в этом режиме создаются или изменяются конфигурационные файлы для Автономного сервера.
- Infobase – предназначен для выполнения различных действий с информационными базами: создание, загрузка/выгрузка, импорт/экспорт и т.д.
Заключение
Спасибо всем, кто дочитал до конца. Статья получилась значительно больше, чем я предполагал, создавая заготовку. Надеюсь, что я не зря потратил силы и время, и Вы открыли для себя что-то новое.
Установить(и запустить) службу RAS на серверах приложений 1С под Windows. Через RAS мы будем получать данные от этого СП 1С . Установить службу можно сделать такой командой:
"C:\Windows\System32\sc.exe" create "1C:Remote Administation Serive (RAS)" binPath= "\"C:\Program Files\1cv8\8.3.12.1685\bin\ras.exe\" cluster --service --port=1545 ИМЯ_СЕРВЕРА:1540" start= auto
Для автоматической установки службы RAS можно воспользоваться скриптом func.install_ras.ps1 из раздела загрузки.
INSERT INTO "public"."ras_servers"("host_name", "ras_port") VALUES ('ИМЯ_СЕРВЕРА_1', 1545) RETURNING *;
INSERT INTO "public"."ras_servers"("host_name", "ras_port") VALUES ('ИМЯ_СЕРВЕРА_2', 1545) RETURNING *;
INSERT INTO "public"."ras_servers"("host_name", "ras_port") VALUES ('ИМЯ_СЕРВЕРА_N', 1545) RETURNING *;
Теперь нам нужно создать несколько служебных таблиц, чтобы хранить в них ссылки на данные из главной таблицы соединений.
INSERT INTO "public"."apps"("name", "description") VALUES ('COMConnection', 'COM-соединение') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('WSConnection', 'Сессия веб-сервиса') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('BackgroundJob', 'Фоновое задание') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('SystemBackgroundJob ', 'Системное фоновое задание') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('SrvrConsole', 'Консоль кластера') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('COMConsole', 'COM-консоль кластера') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('JobScheduler ', 'Планировщик') RETURNING *;
INSERT INTO "public"."apps"("name", "description") VALUES ('RAS', 'Сервер администрирования') RETURNING *;
Таблица со списком процессов сервера 1С . В ней будет храниться неизменяемая информация о процессах СП 1С (она нужна нам для получения имени рабочего сервера для сессии)
FOREIGN KEY("ras_server_by_id") REFERENCES hosts(id) ON DELETE SET DEFAULT, --ссылка на имя RAS-сервера, с которого были получены данные
FOREIGN KEY("infobase_by_id") REFERENCES infobases(id) ON DELETE SET DEFAULT, --id информационной базы из таблицы infobases
FOREIGN KEY("process_by_id") REFERENCES processes(id) ON DELETE SET DEFAULT, --id процесс СП 1C из таблицы processes
FOREIGN KEY("user-name_by_id") REFERENCES users(id) ON DELETE SET DEFAULT, --id пользователя из таблицы users
FOREIGN KEY("app-id_by_id") REFERENCES apps(id) ON DELETE SET DEFAULT, --id приложения из таблицы apps
FOREIGN KEY("license_by_id") REFERENCES licenses_db(id) ON DELETE SET DEFAULT, --размер ключа (на сколько он пользователей)
Для выборки данных о лицензиях нам понадобится отдельный View, ибо с использованием лицензий не всё так просто.
при выдаче клиентскому приложению службой HASP LM для каждого пользовательского сеанса(сессия RDP или локальное подключение Windows) на клиенте выдаётся одна аппаратная лицензия. При этом с этой одной лицензией можно работать в разных базах.
как считать программные лицензии, полученные локально клиентским приложением я ещё не определился, к ним применяется такой же порядок, как для аппаратных, выданных клиенту.
для серверов, не являющихся терминальными (отбираются через view_not_terminal_ids ) агрегируются все подключения с каждого хоста для каждого уникального ключа;
для терминальных серверов ( view_terminal_ids ) применяется дополнительная агрегация и по имени пользователя - применяется допущение, что пользователь, работающий из терминальной сессии в разных базах, будет работать там под одним именем;
После этого нужно настроить скрипт сбора данных (см. раздел загружаемых файлов) - отредактировать его и поменять параметры подключения к Postre .
Сначала нужно добавить новый DataSource с типом PostgreSQL и данными для подключения к нашему серверу с данными:
И посмотреть утилизацию ключей по типам (обратите внимание, что многопользовательские ключи на 20, 50 и 100 лицензий обладают одинаковым идентификатором - ORGL8. А ещё для клиентских лицензий мы не может узнать какой HASP LM их выдал, поэтому они агрегируются сразу по всем ключам одного типа и значение для графика таких ключей может быть больше ёмкости одного ключа):
Специальные предложения
Весь процесс сбора данных есть в ЦКК. Немного его допиливаем, а логику аггрегации лицензий выносим в отчет. Или в алгоритм заполнения мониторинговой БД, если используется сторонняя система мониторинга. В частности, я шлю в Zabbix посредством ВК, реализующей Zabbix sender.
(3) Так экономнее: агент сам по себе в 1С ходить не умеет, типовое решение - агент читает stdout дочернего процесса. Который еще нужно запустить, потратив на это системные ресурсы.
Может это и велосипед, не знаю.
Но велосипед боевой )
Как совет - по хорошему надо просто серверам ограничить доступ к аппаратным лицензиям.
Уберете путаницу и количество свободных лицензий увеличите
У в качестве центра мониторинга - Zabbix. Он сразу избавляет вас от 2,4,5 пукнта. Плюс есть агент, который сам отправляет данные серверу.
Мониторинг "железных" лицензий прямо на хосте, где они установлены. Так честнее и проще.
Ну и графана для красоты (sql-запросы пилить не надо, так как есть интеграция с заббиксом, - достаточно выбрать показатель/item).
(8) Мониторинг железных ключей - это хорошо. Но он работает у Вас только под Win.
И ещё - если выдаёте железные ключи сервером, то вы не знаете, сколько их выдано. Ибо эти данные не получить из ключа, увы.
Буду рад, если опровергните меня по любому из пунктов.
В конце хочу добавить, что данный мониторинг не ограничивается только лишь ключами ;)
О разнообразии применений собираемых данных, по мере накопления UseCases, напишу ещё одну статью.
И ещё - если выдаёте железные ключи сервером, то вы не знаете, сколько их выдано. Ибо эти данные не получить из ключа, увы.
Буду рад, если опровергните меня по любому из пунктов.
Здесь у многих заблуждение. Да, в списке сессий будет видна только одна запись самого сервера 1С, но ключ же как-то понимает сколько ключей он раздал. Эта цифра (без детализации по хостам) видна и в аладдиновском мониторе, и может быть получена программно, используя dll-ку.
Кросплатформенность сейчас, конечно, в моде, но не настолько, чтобы фанатично первым делом переходить на линукс. Впрочем, это Ваши предпочтения и требования.
Я за более взвешенный подход: использовать то, что лучше и удобнее для каждой конкретной задачи. Возможно, у Вас так, но из статьи этого не видно.
Здесь у многих заблуждение. Да, в списке сессий будет видна только одна запись самого сервера 1С, но ключ же как-то понимает сколько ключей он раздал. Эта цифра (без детализации по хостам) видна и в аладдиновском мониторе, и может быть получена программно, используя dll-ку.
Либо я чего-то не знаю, либо Вы.
Я утверждаю (и мои слова подкреплены ответом из 1С) о том, что получить количество утилизированных СП 1С лицензий из аппаратного ключа средствами, в первую очередь, Alladdin Monitor, нельзя.
Можете показать как вы получаете количество выданных СП 1С лицензий из многопользовательского ключа HASP?
По поводу остальных выводов и заключений:
1. Для меня перспектива - кроссплатформенность. Делать сейчас одно, а потом переделывать в другое можно. Но это не мой выбор.
2. Расскажите о том, как сделано у Вас. Мне очень интересно.
Я утверждаю (и мои слова подкреплены ответом из 1С) о том, что получить количество утилизированных СП 1С лицензий из аппаратного ключа средствами, в первую очередь, Alladdin Monitor, нельзя.
Конечно, оно так. Но нужно помнить один нюанс. Занятые лицензии не увидеть, если Ваш ключ воткнут непосредственно в сервер 1С. Тогда получение лицензии идет мимо службы HASP.
А, вот, если для ключа выделить отдельную машину (мы, например, по серверам СУБД распихали), то правильное количество лицензий начнет показывать даже Alladdin Monitor. Собственно, так используем и мониторим.
Так я уже написал в первом посте. Zabbix используются для мониторинга железа, операционной системы, а мы туда еще простенькими PowerShell коммандлетами пропихиваем свои метрики бизнес-приложения.
Я тут америку не открыл и рекламировать это смысла не вижу. Это все равно что запилить статью, например, о том как здорово я установил платформу на 50+ пользовательских компьютеров при помощи простеньких команд.
Свои собственный решения хороши тем, что в них у Вас полная уверенность. Но передать другому специалисту их нельзя. Он их выбросит и напишет свои скрипты. На Заббикс в данном случае нужно смотреть как на универсальный и мощный инструмент, своего рода Платформа, которая уже из коробки может очень многое. Плюс всегда есть Агент, который сам выполнит скрипт и будет сообщать об ошибках. А если машина ушла в небытие, то о недоступности Агента сообщит уже Сервер. И, если не прикручивать к нему для красоты Графану, то одного Заббикса будет уже достаточно.
Конечно, оно так. Но нужно помнить один нюанс. Занятые лицензии не увидеть, если Ваш ключ воткнут непосредственно в сервер 1С. Тогда получение лицензии идет мимо службы HASP.
А, вот, если для ключа выделить отдельную машину (мы, например, по серверам СУБД распихали), то правильное количество лицензий начнет показывать даже Alladdin Monitor. Собственно, так используем и мониторим.
Я знаю о трёх способах выдачи лицензий сервером приложений 1С:
1. Выдачи из ключа под сервером. Этот способ используется всегда первым. Есть ли служба nethasp, нет ли её, СП 1С всегда начинает выдавать лицензии из ключа под собой.
2. Программные лицензии. Здесь всё просто и очевидно. Нечего и добавить.
3. Лицензии из сетевого ключа (прописанного в nethasp.ini). И вот здесь, увы, Alladdin Monitor бессилен. Он показывает корректно только лицензии, полученные клиентом. А лицензии, выданные СП 1С он не покажет верно. Можете проверить. Это так. И 1С это подтверждает.
А если машина ушла в небытие, то о недоступности Агента сообщит уже Сервер. И, если не прикручивать к нему для красоты Графану, то одного Заббикса будет уже достаточно.
Zabbix я тоже использую. Но не для метрик работы 2000 сеансов. Это чрезвычайно избыточно - хранить все эти данные в Zabbix. Совершенство в многообразии.
Все уже проверено до Вас. Просто Вы неверно поняли то, что написала 1С и корректировать свою точку зрения не хотите.
(14) То, что Вы видите соединения от сервера в ключе, не значит, что Вы видите количество утилизированных ключей ))
И да, я действительно не хочу корректировать свою точку зрения. Просто потому, что я проверял внимательней - сравнивал количество записей в Alladdin Monitor с количеством лицензий, утилизированных в консоли администрирования.
Мдаа, а ещё с Вашей стороны в высшей степени неразумно делать выводы о понимании мною письма, содержимого которого Вы даже не знаете. Ну что ж, давайте посмотрим вместе:
Если захотите проверить нормально, а не на отъ. сь, то пишите, если посчитаете нужным.
Удачи с математикой ;)
Всем привет. Эта тема очень важна, так как она помогает восстановить информационную базу с вашего компьютера, если вы вдруг случайно ее удалили из списка информационных баз или удалили саму программу, так как учебная версия может очень часто ломаться и глючить.
В этой статье (уроке) я вам покажу как сделать восстановление и дальнейшую работу с ИБ.
Если что-то непонятно или хотите узнать, вы всегда можете подписаться на мой канал или вступить в группу, которая создана специально для обучающихся (ссылки можно найти ниже).
Восстановление информационной базы происходит очень просто. В данном случае, это скорее не само восстановление ИБ, а восстановление к ней доступа, так как она находится у вас на компьютере и просто вы наверное об этом не знаете (по крайней мере точно не все знают).
Когда мы открываем окно запуска платформы (Рисунок 1) и добавляем новую ИБ, то по умолчанию платформа создает папку в следующем месте "Диск С. Документы".
Найдите у себя эту папку и там вы увидите у себя то количество папок, сколько раз вы создавали информационные базы (Рисунок 2)
Вот с помощью этих папок мы и можем восстановить доступ к нашему приложению.
Скорее всего, у вас будет 2 такие папки, так как на уроках мы создали только две ИБ (одна основная, а вторая резервная и в нее мы загружали файл с расширением ".dt").
Как выяснить какая именно нужна папка? Нужно посмотреть на ее дату и постараться вспомнить когда именно вы работали с программой (или же пробовать все по очереди).
Перейдем к практике. Откроем окно запуска платформы и нажмем кнопку "Добавить". В новом окне выберем "Добавление в список существующей ИБ" (Рисунок 3) и нажмем "Далее"
В следующем окне дадим имя "Восстановление" и нажмем на многоточие, чтоб там выбрать папку с информационной базой. Нужно выбрать папку "InfoBase1" (Рисунок 4) и нажать "Выбор папки"
После этого нажать "Далее" и "Готово". как только нажмете "Готово" у вас автоматически выйдет предупреждение (Рисунок 5). Нажмите "Да"
После этого она появится у вас в списке (Рисунок 6)
Это предупреждение было о том, что у вас в списке уже есть ИБ, которая подключена к этой папке и это означает, что их две, которые будут мешать друг другу.
Выделите ИБ "Восстановление", нажмите на кнопку "Конфигуратор" и убедитесь в том, что вы действительно подключились к папке.
Этот способ работает тогда, когда вы случайно из главного окна удалили свою ИБ или удалили саму программу, то вы всегда сможете к ней подключиться, так как при удалении из списка и при удалении программы, все папки "InfoBase" остаются на диске с по пути "С. Документы"
Вот вы узнали еще один способ работы с платформой. И это только начало, самое интересное даже не начали.
На этом закончим, чтобы вы смогли усвоить то, что мы только что прошли.
В следующей статье будет тема "выгрузка ИБ в разных форматах" , а потом перейдем к работе с новым объектом дерева конфигурации "Справочники". Все это и многое другое на канале "GeekRazrab"
Всем спасибо. Задать вопросы, которые у вас возникли вы можете, написав комментарий или вступить в группу и задать там свой вопрос. Ссылка для вступления в группу - t.me.Apiscourses
Утилита управления "Автономным сервером" может не только управлять. Какие возможности можно использовать уже сегодня? Разбираем с примерами и ищем отличия от привычных методов.
Замечательная статья и очень интересный инструмент! Даже странно, что никакой публичной информации о нем.
Отличная статья!
Это получается, что разработчики огромную дыру в безопасности сотворили, позволяя выгружать базу данных без авторизации.
Интересно, какие библиотеки требуются для работы инструмента, возможно ли создать portable-версию?
Это получается, что разработчики огромную дыру в безопасности сотворили, позволяя выгружать базу данных без авторизации
Нет, немного не так. Нет авторизации в информационной базе . Но есть авторизация СУБД. Т.е. выгрузить базу без соответствующих прав не выйдет.
Используются те же dll, что и "обычным" кластером. Если собрать в папку все используемые библиотеки, должно работать. Я пробовал, но не довёл эксперимент до конца. Некоторые функции у меня работали. А некоторые - нет. Причем уже без явной ругани что не хватает такой-то библиотеки.
Итоговый рабочий вариант выгрузки:
>ibcmd infobase dump --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 --user= --password= "%tmp%\sb_demo.dt"
(57) Да, похоже что направление развития утилиты выбрано совсем не то, что позволяло бы расширить её использование. Добавили авторизацию ИБ, требование серверной лицензии.
Хороший инструмент ibcmd получается у 1С.
По описанию АПИ (ком.строка, файл настройки) очень похож на наш, уже давно существующий, vanessa-runner, использующий штатные средства Конфигуратора/Предприятия.
Хорошо бы, чтобы утилита ibcmd научилась работать не только с Автономным сервером )
Тогда будет счастье.
ЗЫ Апдейт - я неверно понял, оказывается, эта утилита уже работает не только с автономным сервером. Это радует!
Артур, так я об этом и пишу. Она как раз и работает не только с автономным сервером , но и независимо.
Как раз для ваших инструментов и отличная замена пакетному режиму.
По крайней мере, я думаю что работа с Храном будет. И Gitsync, deployk-у можно будет педелать на использование ibcmd.
Остается конечно проблема с запуском обработчиков обновления. Это без клиента никак сейчас не сделать.
Хотя, вот есть ведь у Платформы сейчас служебное фоновое задание UpdateConfigurationLicense, запускаемое после обновления БД.
Думаю, что нет технических препятствий (для разработчиков Платформы) к реализации выполнения обработчиков обновления полностью фоново, без запуска клиента. Но это, как говорится, уже отдельный разговор.
(11) Написал не в ту ветку)) это было по поводу ibsrv.
У нас просто как раз 3 пользователя, попробовали по сети - скорость отличная. Осталось запустить ibsrv как службу и пользоваться.
(12) Так в ветке про ibsrv я даже пример регистрации службы приводил.
А насчет запуска как службы произвольного консольного приложения или даже скрипта PowerShell, со временем будет заметка. Лежит у меня в черновиках, про отслеживание изменений каталога Хранилища с целью запуска синхронизации по событию, а не по расписанию.
У нас просто как раз 3 пользователя, попробовали по сети - скорость отличная. Осталось запустить ibsrv как службу и пользоваться
Максим, Вы в ветке про ibsrv этот комментарий продублируйте, пожалуйста, чтобы он был в контексте. Думаю, кому-то Ваш опыт поможет.
(16) Михаил, хотя вопрос адресован вероятно не мне, я попробую ответить.
Подключаемое оборудование работает на клиенте и, я думаю, вариант взаимодействия клиента с сервером на нем никаким образом не может сказываться. На практике еще не проверял, нет под рукой сейчас ничего из подключаемого.
Не подскажете, что за параметр --system=
Это из help к ibcmd. Со всеми остальными командами вроде ясно, а про этот параметр ничего не нашел.
(19) Алексей, похоже я пропустил этот параметр, когда изучал тему. Поискал сейчас и тоже ничего не нашел. Задал вопрос разработчикам на партнерском форуме. Как ответят, ретранслирую сюда или дополню в статье.
Системный конфигурационный файл используется для "тонкой" настройки работы автономного сервера. В настоящий момент, его содержимое не задокументировано.
Подскажите, вы упомянули что достоинство это утилиты, что она не требует локального ключа.
А если работать через конфигуратор, то не ГитКонвертер, ни Gitsync без локального ключа не заработает на сервере?
(23) Алексей, Конфигуратор в пакетном режиме не работает без лицензии. И GitSync и ГитКонвертер работают именно через пакетный режим Конфигуратора, т.е. формируют командную строку запуска Конфигуратора с необходимыми ключами.
Некоторое время назад, когда для одного из проектов делал синхронизацию Хранилища с Git-ом, еще на "старой" версии 2.4.3 GitSync, как раз столкнулся с проблемой что невозможно было запустить пакетный режим для автоматически создаваемой временной файловой базы, т.к. лицензии раздавались сервером. В тот раз мне пришлось немного "допилить" GitSync, чтобы он мог использовать в качестве временной существующую серверную базу.
Сейчас, "новый" GitSync версии 3.0 позволяет использовать серверную базу в качестве временной. Я писал о новом GitSync небольшую заметку .
Чего не хватает для полного счастья
Перечислю функционал, который хотелось бы увидеть в релизе (первоочередные хотелки):
- Инкрементальная выгрузка в XML только тех файлов, версии которых изменены.
Сейчас доступна только полная выгрузка в XML. - Работа с Хранилищем конфигураций: выгрузка версий, получение отчета по версиям.
- Экспорт непосредственно в формат EDT.
Об этом отдельно ниже. - Логирование в Технологическом Журнале в полном объеме.
Сейчас привычных событий SDBL, DBMSSQL, DBPOSTGRS, DBV8DBENG в ТЖ нет. Пишется только служебное SYSTEM.
Мне представляется, что утилита ibcmd получилась очень функциональным и универсальным инструментом. Возможно, даже более универсальным, чем изначально предполагалось. И сейчас, пока инструмент в статусе беты, у нас есть возможность повлиять на его дальнейшее развитие. Одним из применений и векторов развития мне видится использование в контурах CI-CD. Как для "традиционной" разработки с использованием Хранилищ, так и для работы в новом формате EDT.
Чтобы заменить пакетный режим Конфигуратора в процессе синхронизации "традиционной" разработки с репозиторием Git, не хватает только возможности работы с Хранилищем.
В своей переписке на партнерском форуме с разработчиками я обозначил такой вектор возможного развития инструмента и получил обещание проанализировать и подумать. Ниже привожу цитату своего описания возможного сценария использования. Здесь я защищал предложения включить возможность работы с Хранилищем и выгрузки в формате EDT.
- перевода существующих разработок в формат EDT
- совместной работы над общим Проектом, команд, ведущих разработку "традиционным методом" в Хранилище и "новаторских" с EDT. Пример такой работы приведен в статье "Постепенный переход на разработку в EDT".
- синхронизации Хранилища с репозиторием Git для целей CI-CD.
- необходимость установки Клиента и использование клиентских лицензий
- необходимость установки java
- необходимость установки самой EDT для конвертации XML-EDT
Режим "infobase"
Возможности утилиты я продемонстрирую на примерах. В замечаниях будут указаны особенности, определенные экспериментально или в переписке с разработчиками на партнерском форуме.
Все примеры буду приводить с заполнением параметров командной строкой. Но в каждом из них можно вместо общих ключей указать путь к файлу конфигурации подобным образом:
Создание базы
Начнем, как обычно, с самого простого примера. Создадим файловую базу.
C:\Program Files (x86)\1cv8\8.3.14.1630\bin>ibcmd infobase create --db-path="d:\test\demo_db"
[ INFO] Создание информационной базы.
[ INFO] Создание информационной базы успешно завершено
В результате выполнения команды, создан каталог "d:\test\demo_db" и в нём размещена пустая база 1С – файл 1Cv8.1CD (и пара служебных файлов .cfl)
Одновременно с созданием, одной командой можно выполнить дополнительные действия:
- Загрузить базу из dt-файла
- Загрузить конфигурацию из cf-файла
- Загрузить конфигурацию из XML-файлов
Создать и загрузить выгрузку из dt-файла.
>ibcmd infobase create --db-path="d:\test\demo_db" --restore="E:\1C_templates\1c\smallbusiness\1_6_18_156\ОпцииВкл.dt"
C:\Program Files (x86)\1cv8\8.3.14.1630\bin>ibcmd infobase create --db-path="d:\test\demo_db" --restore="E:\1C_templates\1c\smallbusiness\1_6_18_156\ОпцииВкл.dt"
[ INFO] Создание информационной базы.
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка информационной базы.
[ INFO] Загрузка информационной базы успешно завершена
Создать и загрузить Конфигурацию из cf-файла.
Для разнообразия создадим новую базу с размещением в СУБД. Добавляем ключ загрузки из cf-файла и путь к нему. Повторяющиеся ключи и параметры в дальнейших примерах будут затенены серым шрифтом.
>ibcmd infobase create --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 --create-database --load="%tmp%\sb_demo.cf"
C:\Program Files\1cv8\8.3.14.1630\bin>ibcmd infobase create --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 --create-database --load="%tmp%\sb_demo.cf"
[ INFO] Создание информационной базы.
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка конфигурации.
[ INFO] Загрузка конфигурации успешно завершена
Замечание. При создании базы в СУБД, смысл команды create правильнее было бы назвать «инициализацией», т.к. выполняется создание структуры таблиц и индексов в существующей базе данных. Если же базы данных не существует, будет выдана ошибка. Чтобы при отсутствии базы данных она была создана, требуется указать ключ --create-database , аналогично установке флажка «Создать базу данных в случае её отсутствия» в консоли кластера.
Создать и загрузить Конфигурацию из XML-файлов.
Меняем ключ загрузки на --import и указываем каталог с исходниками.
>ibcmd infobase create --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 --create-database --import="%tmp%\sb_demo_export"
C:\Program Files\1cv8\8.3.14.1630\bin>ibcmd infobase create --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 --create-database --import="%tmp%\sb_demo_export"
[ INFO] Создание информационной базы.
[ INFO] Создание информационной базы успешно завершено
[ INFO] Импорт конфигурации из XML.
[ INFO] Импорт конфигурации из XML успешно завершен
Замечание. Загрузка конфигурации из cf-файла или XML-файлов выполняется в «основную» Конфигурацию информационной базы. Конфигурация базы данных после такой операции остается прежней. Чтобы сразу после загрузки произвести обновление конфигурации базы данных, можно добавить ключ --apply .
Загрузка и выгрузка сf, cfe, dt, xml
Разумеется, загрузку dt, cf, cfe, xml-файлов можно выполнить и отдельными командами, без создания информационной базы. Выгрузка во всех поддерживаемых форматах также присутствует.
>ibcmd infobase restore --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "E:\1C_templates\1c\smallbusiness\1_6_18_156\ОпцииВкл.dt"
>ibcmd infobase dump --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo.dt"
Загрузка конфигурации из cf-файла:
>ibcmd infobase config load --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo.cf"
Выгрузка конфигурации в cf-файл:
>ibcmd infobase config save --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo.cf"
Замечание. Для команды выгрузки конфигурации save по умолчанию выгружается конфигурация базы данных, а не основная. Для того, чтобы сохранить основную конфигурацию, необходимо указать ключ --staging
Загрузка конфигурации из XML-файлов:
>ibcmd infobase config import --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo_export"
Выгрузка конфигурации в XML-файлы:
>ibcmd infobase config export --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo_export"
Замечание. Для команд загрузки и выгрузки конфигурации доступно указание ключа --extension и имени расширения, которое нужно загрузить или выгрузить.
Обновление конфигурации базы данных
После загрузки Конфигурации или расширения, конечно же, требуется обновить конфигурацию базы данных.
>ibcmd infobase config apply --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123
C:\Program Files\1cv8\8.3.14.1630\bin>ibcmd infobase config apply --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123
[ INFO] Обновление конфигурации базы данных.
[ INFO] Проверка корректности метаданных.
[ INFO] Обработка структуры базы данных.
[ INFO] Обработка данных: Реструктуризация Перечисление.РезультатыОбработкиЗапросовНаИспользованиеВнешнихРесурсовВМоделиСервиса
.
[ INFO] Новый объект: РегламентноеЗадание.ЧтениеНовостейСлужбыПоддержки
[ INFO] Новый объект: РегламентноеЗадание.ЭкспортОценкиПроизводительности
[ INFO] Изменена структура таблиц базы данных
[ INFO] Принятие изменений.
[ INFO] Обновление конфигурации базы данных успешно завершено
Прочие команды
Без примеров оставлю последние три команды, что есть в текущей версии утилиты.
- config check - проверка конфигурации
- config reset - восстановление конфигурации базы данных.
- clear - очистка информационной базы
Для чего всё это нужно?
Предполагаю, что у Вас уже возник вопрос: «И чем это отличается от пакетного режима Конфигуратора, который делает всё то же самое, и даже больше, давным-давно?». Признаюсь, я ждал этого вопроса.
Отличия от пакетного режима Конфигуратора:
Во-первых, для выполнения описанных действий посредством Конфигуратора, нужно, как минимум, чтобы Клиентская часть Платформы была установлена. С этим не возникает проблем, когда Вы работаете на своем компьютере с локальной базой. Но когда база расположена на сервере, который является только сервером приложений 1С, для загрузок-выгрузок есть следующие варианты:
а) выполнять операции Конфигуратором по сети. Это может занимать очень продолжительное время ввиду особенностей сетевого обмена между компонентами Платформы.
б) устанавливать клиентскую часть Платформы на сервер. Исключительно с целью ускорения выгрузок-загрузок.
А если Ваш сервер – на Linux и без графического интерфейса? Конечно, можно установить пакет Xvfb, эмулирующий вывод на дисплей, но ведь это «костыли», как Вы считаете?
Выполнение действий утилитой ibcmd возможно непосредственно на сервере, без установленного Клиентского приложения. Специально ничего устанавливать не требуется. Утилита присутствует в дистрибутиве сервера приложений 1С.
Во-вторых, клиентское приложение, в частности и Конфигуратор, работающий в пакетном режиме, требует лицензию. И возможность получить лицензию Конфигуратором есть не всегда.
Пример: лицензии выдаются Сервером 1С, локальных лицензий нет. При этом требуется загрузка/выгрузка для файловой базы.
Для выполнения действий утилитой ibcmd лицензия не требуется. Ни клиентская, ни серверная.
В-третьих, все операции с базой, выполняемые Конфигуратором, требуют авторизации в этой базе.
Пример: требуется извлечь конфигурацию из dt-файла, который Вам достался, скажем, из архива и неизвестен пароль пользователя ИБ, обладающего административными правами в ней.
Традиционный способ – создать временную информационную базу в клиент-серверном варианте, чтобы иметь возможность очистки таблицы пользователей. Загрузить в неё dt-файл. Очистить таблицу пользователей базы в СУБД. Перезапустить Конфигуратор. Выгрузить конфигурацию в файл. Удалить временную базу из СУБД.
Для операций, выполняемых ibcmd не требуется авторизация информационной базы. Upd 15.12.21: Ниже, в комментариях, коллеги указывают, что в Платформе версий 8.3.18.1689, 8.3.20.1549 авторизация ИБ уже требуется.
Выполнение той же задачи посредством ibcmd, будет выглядеть следующим образом:
>ibcmd infobase create --db-path="%tmp%\db" --restore="%tmp%\some_infobase.dt"
>ibcmd infobase config save --db-path="%tmp%\db" "%tmp%\some_infobase.cf"
Да, я в знаю что существуют разработки на Инфостарте, позволяющие извлечь конфигурацию в виде cf-файла непосредственно из dt-файла. Здесь я описываю штатные механизмы.
В-четвертых, для выгрузки конфигурации посредством ibcmd, не имеет значения, запущен ли в данный момент Конфигуратор этой базы у кого-то еще или нет. Просто потому что мы не запускаем Конфигуратор.
Более того, я пока не знаю, расценивать ли это как баг или как фичу, но для выгрузки dt-файла не требуется монопольный режим! Конечно же, пользоваться этим стоит с осторожностью. Не думаю что попытка сделать dt-шник в момент активной работы с базой пройдет без негативных эффектов.
В-пятых. Формат командной строки гораздо проще чем для Конфигуратора. Кроме того, есть возможность использования конфигурационного файла, чтобы не указывать повторяющиеся параметры подключения.
Возможно, Вы сможете добавить еще пару-тройку отличий, если заинтересуетесь инструментом и станете им пользоваться.
Режим "server"
Режим работы server тесно связан с самим «Автономным сервером»
Главным его назначением является формирование корректного файла настроек для Автономного сервера, в формате YML.
Например, приведенная ниже команда, на основании переданных параметров и значений по умолчанию, сформирует файл sb_demo.yml, который далее можно указывать как самому серверу ibsrv, так и утилите управления ibcmd вместо длинной цепочки параметров.
>ibcmd server config init --db-server=localhost --dbms=MSSQLServer --db-name=sb_demo --db-user=test_db_user --db-pwd=test_pwd_123 "%tmp%\sb_demo.yml"
Содержимое созданного файла sb_demo.yml:
На этом, пожалуй, описание режима server можно считать исчерпанным.
Читайте также: