Разбор · 8 мин
Как проверять версию API: учебный пример
На авторском примере общего модуля: проверить версию, параметры и условия вызова, не выдавая его за API платформы.
Вопрос о платформенной функции редко заканчивается одним именем. Нужно знать версию 1С, клиентский или серверный контекст, тип результата и минимальный способ проверить вызов.
Учебный пример платформенного вопроса показывает порядок проверки: версия и контекст выполнения, точная сигнатура, затем минимальный тест. Синтетический SDK не подтверждает реальный метод платформы 1С.
Правильный вопрос уже содержит границы
Вместо «какой метод использовать» спросите: «Какая процедура или функция доступна на сервере в нашей версии платформы, что она принимает, что возвращает и каким минимальным тестом это проверить?» Такой вопрос не позволяет смешать клиентский пример с серверным кодом.
Библиотечный источник и проект отвечают по очереди
Документационный корпус подтверждает сигнатуру, контекст и версию. Проектный индекс показывает, где уже применяется нужный способ и какой режим совместимости используется. Это проектный сценарий; он не входит в публичный демонабор библиотек только для чтения.
Целевая платформа и режим совместимости.
Клиент, сервер и доступность вызова.
Параметры, тип результата и ошибки.
Минимальный положительный и отрицательный сценарии.
Верный пример из другой версии остаётся кандидатом
Даже компилирующийся фрагмент может менять смысл в другой версии. Агент обязан назвать источник и диапазон применимости, а при неизвестной версии — остановиться и запросить её, а не выбирать последнюю доступную документацию.
Тест проверяет не только успешный путь
Положительный сценарий подтверждает тип и обязательные поля. Негативный — поведение при неподдерживаемом контексте, отсутствии обязательного значения или несовместимой версии. Результаты фиксируются отдельно от предположения агента.
Серверный контекст проверяется отдельно
Авторский учебный вопрос: процедура формы должна вызвать общую функцию на сервере. Вход — подтверждённая версия платформы, имя функции, её экспортность и контекст выполнения; ожидаемый выход — ссылка на действующий контракт и минимальный сценарий вызова из разрешённого места. Фраза «она есть в похожей конфигурации» не закрывает ни одно из этих условий.
Решение: сначала найти функцию в документации нужной версии, затем в собственном проекте проверить её наличие и доступность из серверного контекста. Если проект недоступен, оставить место вызова неизвестным. Синтетическая СоздатьОтправление показывает только форму исследования, не реальный метод платформы 1С.
Учебный пример платформенного вопроса на синтетическом аналоге
Текущий авторский корпус не содержит реальную документацию платформы 1С. Поэтому метод разбирается на синтетической функции СоздатьОтправление из route-delivery-bsl-sdk / 1.2.0 / custom; связку с API 2.1.0 и платформой 8.3.20+ подтверждает route-delivery-compatibility / 2.1.0 / custom.
- Сформулировать запрос: «Для какой версии и серверного контекста разрешена СоздатьОтправление? Покажи сигнатуру и источник». Это пример структуры вопроса, а не вызов API платформы.
- Проверить сочетание версий по матрице.
- Открыть BSL-сигнатуру через symbol и сверить Idempotency-Key и поля результата со схемой.
- Решение: не переносить код в рабочую 1С, пока аналогичный факт не найден для реальной платформенной функции; затем запланировать позитивный и негативный тест.
Это учебная аналогия метода исследования. Она не выдаётся за готовый корпус платформенного API 1С.
Что уже можно утверждать, а что нужно проверить
- Синтетическая матрица фиксирована в route-delivery-compatibility / 2.1.0 / custom, сигнатура — в route-delivery-bsl-sdk / 1.2.0 / custom.
- Метод проверки версии переносим на платформенные источники.
- Реальную платформенную функцию по официальной документации.
- Доступность и поведение в целевой версии 1С.