ibcmd и PowerShell: первый шаг к RPA-сопровождению систем 1С

ЦИКЛ «RPA ДЛЯ 1С» · 01 · ПИЛОТ

RPA для 1С: от отдельных команд к управляемому сопровождению

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

Целевая аудитория: администраторы и разработчики 1С, инженеры автоматизации.

Ключевые технологии: 1С:Предприятие, ibcmd, PowerShell 7.2+, XML, CF; RPA и ИИ рассматриваются как дальнейшее развитие.

Задача и выбор инструментов

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

• файловые и клиент-серверные информационные базы;
• несколько версий платформы;
• разные СУБД;
• dev, test, stage и prod;
• XML-исходники, CF/CFE, расширения и унаследованные процессы;
• десятки регламентов, журналов и исключений.

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

Здесь полезна связка из трёх слоёв:

1. ibcmd выполняет поддерживаемые платформой операции без GUI.
2. PowerShell предоставляет типизированные обёртки, журналы и предохранители.
3. В дальнейшем RPA-исполнитель сможет связывать операции с заявками и приложениями, а ИИ-планировщик - помогать с разбором событий и подготовкой плана. Эти компоненты в модуле 0.1.0 не реализованы.

Что такое ibcmd

ibcmd - утилита управления автономным сервером 1С:Предприятия. Она умеет работать в offline-режиме через каталог данных, а также управлять запущенным экземпляром автономного сервера локально или удалённо. В числе официально документированных сценариев - DT dump/restore, операции с CF, применение конфигурации базы данных и экспорт/импорт конфигурации в XML.

Важно не смешивать разные сущности:

• infobase dump создаёт DT-образ;
• infobase restore загружает информационную базу из DT;
• infobase config load загружает CF;
• infobase config apply обновляет конфигурацию базы данных и при необходимости перестраивает структуру;
• infobase config export/import работает с XML-файлами конфигурации;
• infobase config check относится к проверке конфигурации, а не является полным аналогом «Тестирования и исправления» данных.

Утверждение «restore исправляет логическую и ссылочную целостность» неверно: в CLI ibcmd команда restore относится прежде всего к загрузке DT. Тестирование и исправление данных нужно рассматривать отдельно: через поддерживаемые конкретной версией инструменты платформы, пакетный режим Конфигуратора, специализированные административные утилиты и регламент СУБД.

Почему PowerShell

PowerShell 7 работает на Windows, Linux и macOS. Для неоднородной инфраструктуры это позволяет сохранить единый язык автоматизации, хотя пути к бинарникам, права, поставка платформы и возможности самой 1С остаются зависимыми от ОС.

В обёртке можно унифицировать:

• массив аргументов вместо хрупкой склейки командной строки;
• одинаковая обработка exit code;
• общий формат журналов;
• -DryRun, -WhatIf и -Confirm;
• единая политика секретов и подтверждений.

PowerShell здесь выбран для команд с типизированными параметрами и работы с процессами и JSON без дополнительного парсера. Если команда уже ведёт автоматизацию на OneScript или другом стеке, переносить её ради этой статьи не требуется: имеет смысл перенять проверки и формат результата.

Практика: проверяем DryRun без базы 1С

Для первого запуска достаточно PowerShell 7.2+ и файлов модуля. Утилита ibcmd и база для DryRun не нужны. Распакуйте комплект, откройте PowerShell в его корневом каталоге и выполните:

1

pwsh -NoProfile -NonInteractive -File ./examples/04-article-dry-run.ps1

Скрипт импортирует модуль относительно собственного расположения, проверяет, что путь ./artifacts/article-dry-run свободен, и собирает команду экспорта. При занятом пути он останавливается, чтобы существующие файлы не исказили проверку. Ниже основной вызов из скрипта:

1
2
3
4
5
6
7

$result = Export-1CConfigurationXml `
    -IbcmdPath 'ibcmd' `
    -ConnectionArguments @('--config=./config/demo.yml', '--password=DEMO-ONLY') `
    -OutputDirectory './artifacts/article-dry-run/config-xml' `
    -LogPath './artifacts/article-dry-run/export.log' `
    -SensitiveValues @('DEMO-ONLY') `
    -Sync -DryRun -Confirm:$false

DEMO-ONLY - вымышленное значение для проверки маскирования. Файл demo.yml в этом опыте не читается. -Confirm:$false здесь используется вместе с -DryRun, чтобы проверка выполнялась без диалога; переносить отключение подтверждения в сценарий реального изменения базы не следует.

Фактический результат запуска на Windows 11 (сборка 22631), PowerShell 7.6.5, модуль Ibcmd.DevOps 0.1.0:

1
2
3
4
5
6
7
8

{
  "Command": "ibcmd infobase config export --config=./config/demo.yml --password=<redacted> --sync ./artifacts/article-dry-run/config-xml",
  "DryRun": true,
  "ExitCode": null,
  "OutputDirectoryExists": false,
  "LogExists": false,
  "SecretMasked": true
}

В строке команды сохранились параметры экспорта, учебный пароль заменён на <redacted>. Значение ExitCode: null означает, что дочерний процесс не запускался. Каталог XML и файл журнала отсутствуют. Скрипт проверяет эти условия и завершается ошибкой при несоответствии.

Этот результат проверяет сборку отображаемой команды и поведение DryRun. Он не подтверждает совместимость ключей с конкретной версией ibcmd, права доступа или корректность экспорта. Строка Command служит для просмотра; при реальном запуске модуль передаёт аргументы через ProcessStartInfo.ArgumentList.

Что делать при ошибке импорта модуля

При первом испытании Windows отклонила импорт файла из скачанного архива: файл не был подписан и имел отметку о загрузке из интернета. После проверки исходного кода была снята отметка только с файла модуля; системная политика RemoteSigned осталась прежней. В корпоративной среде используйте принятый порядок проверки и подписи скриптов.

Что проверить перед реальным экспортом

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

Ограничения версии 0.1.0

Модуль маскирует перечисленные значения в отображаемой команде, но сохраняет stdout/stderr дочернего процесса без такой очистки. Образец policy.sample.json не подключён к исполнителю и сам по себе ничего не запрещает. Параметры подтверждения PowerShell также не заменяют проверку полномочий.

У текущей реализации есть ограничения, которые важно учитывать при испытаниях: часть функций создаёт выходной каталог до ShouldProcess, поэтому -WhatIf нельзя считать полной гарантией отсутствия изменений файловой системы. У Import-1CConfigurationXml параметр -AllowReplace обязателен, однако переданное значение $false отдельно не отклоняется. До устранения этих ограничений использовать модуль как защитный механизм для PROD нельзя.

Операции с конфигурацией: XML и CF

Справка целевой версии

CLI платформы развивается. В документации разных версий встречаются короткие ключи --db-server, --db-pwd, --db-name и более длинные варианты --database-server, --database-password, --database-name. Поэтому модуль не кодирует универсальную «модель подключения», а принимает ConnectionArguments как массив.

Первым шагом должен быть preflight:

1
2
3
4
5
6

Import-Module ./src/Ibcmd.DevOps/Ibcmd.DevOps.psd1 -Force

Test-IbcmdAvailable -IbcmdPath /path/to/ibcmd
Get-IbcmdHelp -IbcmdPath /path/to/ibcmd
Get-IbcmdHelp -IbcmdPath /path/to/ibcmd `
    -CommandPath @('infobase', 'config')

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

Экспорт и импорт XML

Официально поддерживаются полный и частичный XML export/import в иерархическом формате. Линейный формат автономным сервером не поддерживается.

1
2
3
4
5
6
7

Export-1CConfigurationXml `
    -IbcmdPath /path/to/ibcmd `
    -ConnectionArguments @('--config=/secure/1c/demo.yml') `
    -OutputDirectory ./artifacts/config-xml `
    -Sync `
    -LogPath ./artifacts/logs/export.log `
    -Confirm

Для полного import есть принципиальный риск: документация прямо говорит, что операция полностью заменяет конфигурацию, описанную серверным config-файлом. Для обозначения намерения в вызове предусмотрены -AllowReplace и подтверждение; ограничения проверки этого параметра в версии 0.1.0 описаны выше.

1
2
3
4
5

Import-1CConfigurationXml `
    -ConnectionArguments @('--config=/secure/1c/build.yml') `
    -InputDirectory ./src/config-xml `
    -AllowReplace `
    -Confirm

CF: сохранение, загрузка, применение

Сохранение CF отделено от загрузки. Загрузка CF, в свою очередь, отделена от config apply.

1
2
3
4

Save-1CConfigurationFile `
    -ConnectionArguments @('--config=/secure/1c/build.yml') `
    -OutputCfPath ./artifacts/release.cf `
    -Confirm

1
2
3
4
5

Install-1CConfigurationFile `
    -ConnectionArguments @('--config=/secure/1c/test.yml') `
    -CfPath ./artifacts/release.cf `
    -Apply `
    -Confirm

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

DT и резервное копирование

Официальное руководство разрешает создавать DT через ibcmd infobase dump, но одновременно предупреждает:

• во время операции у базы не должно быть соединений;
• dump информационной базы не следует использовать как основной способ резервного копирования;
• для клиент-серверных баз нужно применять штатные средства соответствующей СУБД.

Поэтому в коде приложенного прототипа функция называется Export-1CInfobaseImage, а не Backup-1CInfobase. DT полезен для переносимого образа, миграции, стенда или дополнительного контрольного артефакта. Для «огромной» продуктивной базы он не заменяет online backup, full/differential/log backups, PITR и проверку восстановления.

Файловые базы и chdbfl

Файловый «зоопарк» - отдельный контур. chdbfl предназначена для автономной проверки и исправления файловых информационных баз, но автоматизация ремонта требует особенно осторожной политики: копия 1Cv8.1CD, отсутствие пользователей, журнал, предварительная проверка без исправления и подтверждение человека.

В версии 0.1.0 автоматизация chdbfl намеренно отсутствует.

Реестр ландшафта

В приложении используется JSON, а не YAML: ConvertFrom-Json входит в PowerShell, тогда как YAML потребовал бы внешнего модуля или собственного парсера.

Фрагмент landscape.sample.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "schemaVersion": "0.1",
  "infobases": [
    {
      "id": "erp-prod",
      "kind": "client-server",
      "environment": "prod",
      "criticality": "A",
      "platformVersion": "VERIFY-ME",
      "connectionArguments": [
        "--config=/secure/1c/erp-prod.yml"
      ]
    }
  ]
}

Реальный реестр должен содержать не пароли, а ссылки на секреты, владельца, окно обслуживания, RPO/RTO, способ backup/restore, версии платформы и конфигурации, допустимые операции, зависимости и контакты эскалации.

VERIFY-ME в образце - незаполненная версия платформы. Исполнитель будущего робота должен отклонять такую запись до запуска операции. В модуле 0.1.0 чтение реестра и эта проверка пока не реализованы.

DevOps-конвейер

Команды ibcmd можно включать в сборочный конвейер. Ниже предложенная последовательность; это схема процесса, а не реализованный в комплекте CI/CD workflow:

Конвейер должен хранить:

• версию платформы и ibcmd;
• хэш исходников и артефакта;
• параметры запуска без секретов;
• exit code и журналы;
• результат тестов;
• автора и подтверждение операции;
• план отката.

Время выполнения операций зависит от объёма конфигурации, версии платформы, СУБД, CPU, I/O, антивируса, топологии и состояния базы. Корректный benchmark требует методики и повторяемых измерений на известном стенде.

Дальнейшее развитие: ИИ-планировщик

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

Предлагаемая схема:

Автономно допустимы чтение инвентаризации, получение --help, анализ журналов, расчёт хэшей и подготовка плана. DT dump, XML import, CF load/apply, завершение сеансов и любые изменения PROD должны требовать подтверждения. Repair/restore/drop PROD автономно запрещены.

Перед исполнением проверяются целевая база, окружение, допустимая операция и согласование. Запрещённый план отклоняется; требующий согласования ждёт решения человека. Согласование относится к конкретной версии плана: изменение цели или параметров требует новой проверки. После запуска сохраняются результат, ошибки и сведения о фактически выполненных шагах.

От отдельных команд к RPA-сопровождению

В корпоративной системе операция редко заканчивается одной командой. Обновление тестовой базы связано с заявкой в Service Desk, выбором нужной версии, окном работ, проверкой интеграций и уведомлением ответственного. Часть этих шагов доступна через API и командную строку; для другой части остаются веб-формы и настольные приложения. На этих переходах мы и предлагаем развивать RPA - роботизацию повторяемых действий в пользовательских интерфейсах.

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

Пример будущего сценария: подготовить тестовый контур

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

1. Робот получает заявку с идентификатором целевого контура, версией артефакта и ответственным за согласование. По реестру сверяет адрес базы и её принадлежность к test; одного слова «тестовая» в названии недостаточно.
2. Проверяет доступность инструментов, окно обслуживания, свободное место и отсутствие конфликтующего задания. Для обновления существующего стенда проверяет предусмотренный регламентом способ восстановления.
3. Формирует план: какая конфигурация и куда будет загружена, какие интеграции нужно отключить, как проверить результат. Человек согласовывает конкретный план до изменения состояния систем.
4. Исполнитель вызывает проверенные команды CLI/API. Если отдельная служебная настройка доступна только в форме приложения, RPA открывает нужную форму, сверяет базу и текущие значения, выполняет действие и считывает результат.
5. После операции выполняются контрольные проверки: версия конфигурации, вход в стенд, статус согласованных проверок интеграций. При ошибке процесс останавливается на известном шаге; повторный запуск начинается с проверки состояния, чтобы не повторить уже выполненную загрузку.
6. В заявке сохраняются идентификатор задания, хэш артефакта, результат проверок и обезличенный журнал. Заявка закрывается по подтверждённому результату, а не по факту нажатия последней кнопки.

Что делает сценарий пригодным для сопровождения

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

При работе с интерфейсом будем проверять возможность адресовать элементы по их свойствам и структуре. Например, Microsoft описывает селекторы элементов отдельно для настольных приложений и веб-страниц, а обработку ошибок - для отдельных действий и блоков. Подход и доступность элементов предстоит проверить на выбранном клиенте 1С и конкретных формах. Это не обещание совместимости любой RPA-платформы со всеми конфигурациями. См. работу с UI-элементами и обработку ошибок.

Гетерогенность здесь влияет на исполнение каждого шага: версии платформы и конфигураций, файловые и клиент-серверные базы, Windows и Linux, разные СУБД, веб-клиент и настольный клиент. Поэтому исполнитель выбирается по возможностям конкретного узла. Сеанс RPA, работающий с настольным приложением, имеет свои требования к ОС, учётной записи и доступности интерфейса; кроссплатформенность PowerShell их не отменяет.

Что разберём в продолжении цикла

• Реестр и диспетчер заданий. Идентификация баз, разрешённые операции, блокировка конкурирующих заданий и возобновление после сбоя. Результат - воспроизводимое задание с проверяемым статусом.
• RPA на конкретной форме 1С. Выбор элементов, ожидание состояния, тайм-ауты и остановка при изменении интерфейса. Результат - небольшой сценарий и разбор его отказов на указанном стенде.
• Сквозное обслуживание тестового контура. Заявка, согласование, CLI/API, контрольные проверки и отчёт. Отдельно разберём ситуацию, когда один из шагов завершился, а следующий не начался.
• ИИ-помощник оператора. Разбор очищенного журнала и подготовка структурированного плана; проверка полномочий и исполнение остаются у отдельных компонентов.

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

Комплект для повторения

Для повторения примера подготовлен комплект Ibcmd.DevOps-0.1.0-reader-kit.zip. Начните с файла START-HERE.md в корне комплекта. Для проверки DryRun используются только модуль и сценарий examples/04-article-dry-run.ps1.

В комплект включены:

• исходный модуль Ibcmd.DevOps 0.1.0 и его manifest;
• примеры preflight, DryRun, XML export и CF load/apply;
• проверяемый сценарий DryRun из этой статьи;
• образцы реестра и политики для будущего исполнителя;
• результат проверки DryRun и ограничения текущей версии;
• сведения о безопасности и текущем состоянии лицензирования.

Реестры и политика - образцы данных для дальнейшей разработки. RPA-робот, ИИ-планировщик и готовый механизм согласования в этот комплект не входят.

Первоисточники

• 1Ci: управление автономным сервером
• 1Ci: примеры работы, включая экспорт и импорт XML
• 1Ci: рекомендации по резервному копированию
• Microsoft: установка PowerShell
• Microsoft: элементы интерфейса в RPA
• Microsoft: обработка ошибок в desktop flows

Обсудим следующий сценарий

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