180 lines
9.2 KiB
Markdown
180 lines
9.2 KiB
Markdown
# Политика хранилища по слоям конфигурации 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`:
|
||
|
||
```json
|
||
{
|
||
"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С и требует
|
||
явного флага подтверждения.
|
||
|
||
Основная конфигурация подключена к хранилищу:
|
||
|
||
```json
|
||
{
|
||
"method": "repository.layer.connection.set",
|
||
"payload": {
|
||
"base_id": "neft",
|
||
"layer_id": "base",
|
||
"connection_state": "configured",
|
||
"repository_user": "ivanov",
|
||
"confirm_repository_connection_change": true
|
||
}
|
||
}
|
||
```
|
||
|
||
Расширение точно не подключено:
|
||
|
||
```json
|
||
{
|
||
"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`; его эквивалент:
|
||
|
||
```json
|
||
{
|
||
"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`; адаптер нормализует поля до проверки захвата:
|
||
|
||
```json
|
||
{
|
||
"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 и выдаёт для каждого слоя состояние хранилища, общий режим поддержки
|
||
и безопасное следующее действие:
|
||
|
||
```json
|
||
{
|
||
"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`, и адаптер применяет политику найденного слоя, а не клиентский выбор
|
||
слоя.
|
||
|
||
## Захват формы владельца
|
||
|
||
Для формы документа, справочника, обработки или отчёта область захвата задаётся
|
||
точно, без сворачивания к владельцу:
|
||
|
||
```json
|
||
{
|
||
"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`.
|