Политика хранилища по слоям конфигурации 1С

Каждая конфигурация имеет собственную политику: основная конфигурация — слой base, каждое расширение — слой extension:<GUID>. Подключение основной конфигурации к хранилищу не означает подключения расширения и наоборот.

Адаптер работает с метаданными 1С только через SQL. Он не считает SQL-таблицы доказательством нативного захвата объекта в хранилище.

Заявки на захват и явные ручные подтверждения — это служебные данные адаптера, а не данные 1С. Они хранятся в /data/onec-repository-locks.json в named volume Docker adapter-1c-data и переживают пересоздание контейнера. Это хранилище не используется для вывода о нативном захвате и не требует записи в какую-либо базу 1С.

Настройка

В development_layers для каждого фактически используемого слоя задаётся repository.connection_state:

{
  "base": {
    "repository": {"mode": "manual", "connection_state": "configured"},
    "support": {"mode": "unknown"}
  },
  "extension:86d12be8-086c-11f0-925c-0050568c1b38": {
    "repository": {"mode": "none", "connection_state": "not_configured"},
    "support": {"mode": "unknown"}
  }
}

Допустимые состояния:

Состояние	Политика записи
`not_configured`	Слой не подключён к хранилищу; захват не требуется. Ограничения поддержки сохраняются.
`configured`	Подключение известно. В SQL-only режиме нужен запрос и явное подтверждение захвата.
`unavailable`	Подключение предполагается, но проверить его нельзя; нужен запрос и явное подтверждение захвата.
`unknown`	Не делать предположений: запись в слой блокируется до настройки.

Для ручного подтверждения всегда передаётся точный объект и явный флаг user_confirmed_locked. Имя пользователя хранилища берётся из repository_user настройки данного слоя. Поэтому при заполненной настройке его не нужно повторять в каждой заявке или подтверждении. Если клиент всё же передаёт confirmed_repository_user, оно должно совпадать с настроенным именем. Если имя не настроено, подтверждение попросит его явно.

Сохранение факта подключения агентом

Агент может сохранить подтверждённый факт в служебной конфигурации адаптера через repository.layer.connection.set. Метод не меняет SQL-базу 1С и требует явного флага подтверждения.

Основная конфигурация подключена к хранилищу:

{
  "method": "repository.layer.connection.set",
  "payload": {
    "base_id": "neft",
    "layer_id": "base",
    "connection_state": "configured",
    "repository_user": "ivanov",
    "confirm_repository_connection_change": true
  }
}

Расширение точно не подключено:

{
  "method": "repository.layer.connection.set",
  "payload": {
    "base_id": "neft",
    "extension_guid": "86d12be8-086c-11f0-925c-0050568c1b38",
    "connection_state": "not_configured",
    "confirm_repository_connection_change": true
  }
}

При not_configured адаптер устанавливает режим слоя none. При configured или unavailable новый слой по умолчанию получает ручную политику захвата. Рекомендуется сразу передать постоянный repository_user: он сохраняется только в конфигурации адаптера для этого слоя и используется во всех последующих ручных подтверждениях.

Ручное подтверждение захвата

После repository.lock.request клиент должен использовать возвращённый next_call без самостоятельного подбора имён полей. Поля из next_call.params передаются как RPC payload; его эквивалент:

{
  "method": "repository.lock.confirm",
  "payload": {
    "base_id": "neft",
    "request_id": "rreq-…",
    "user_confirmed_locked": true
  }
}

objects, operation и layer_id не передаются повторно: подтверждение берёт их из неизменяемой сохранённой заявки. Если имя пользователя сохранено для слоя, оно тоже не передаётся. Успешный ответ содержит lock_session_id; его необходимо передать в preflight и операцию записи.

Ответ repository.lock.confirm содержит готовый write_context. Его можно передать целиком либо верхнеуровневым полем write_context, либо алиасом repository_lock; адаптер нормализует поля до проверки захвата:

{
  "base_id": "neft",
  "target": {"module_id": "Config:<form-guid>.0"},
  "repository_lock": {"lock_session_id": "rlock-…", "repository_object": "Document.Имя.Form.ИмяФормы", "layer_id": "base"}
}

Если одновременно переданы вложенное и верхнеуровневое значение, они должны совпадать; иначе возвращается repository_lock_context_conflict.

Проверка

repository.layers.audit обнаруживает основную конфигурацию и расширения из live SQL и выдаёт для каждого слоя состояние хранилища, общий режим поддержки и безопасное следующее действие:

{
  "method": "repository.layers.audit",
  "payload": {"base_id": "neft"}
}

Ключевые действия в ответе:

repository_lock_not_required — слой явно не подключён к хранилищу;
request_and_confirm_repository_capture — перед записью требуется подтверждение захвата;
configure_repository_connection_state — слой нельзя менять, пока не установлен один из статусов подключения.

Проверка поддержки выполняется отдельно от хранилища. Для конкретного объекта используйте metadata.write.preflight: разрешение объекта определяет его origin, и адаптер применяет политику найденного слоя, а не клиентский выбор слоя.

Захват формы владельца

Для формы документа, справочника, обработки или отчёта область захвата задаётся точно, без сворачивания к владельцу:

{
  "method": "repository.lock.request",
  "payload": {
    "base_id": "neft",
    "objects": ["Document.тл_Планировщик.Form.ФормаДокументаНовая"],
    "operation": "modify"
  }
}

До создания заявки repository.lock.plan и сама заявка разрешают форму через live SQL, получают GUID формы и сохраняют точную каноническую область. После ручного подтверждения эта сессия не даёт права на соседние формы или модуль владельца.

Также принимается Form.<GUID>. Для него адаптер проверяет связь формы с владельцем по live SQL; при отсутствии готовой производной записи владельца выполняется ограниченный SQL-скан форм поддерживаемых типов владельцев. Если владелец не найден, планирование и заявка завершаются not_found, а не возвращают ложный ready.

9.2 KiB Raw Blame History Unescape Escape