Работа с данными через программный интерфейс без прямых запросов

Курс: БСП 1С: Быстрый старт в стандартные подсистемы12+

В предыдущей теме мы познакомились с общим устройством модуля ОбщегоНазначения. Мы увидели, что БСП (Библиотека Стандартных Подсистем) предлагает готовые инструменты для решения рутинных задач. Сегодня мы сделаем следующий шаг и научимся профессионально работать с данными, используя программный интерфейс библиотеки.

Почему «Запрос» — это не всегда лучший выбор?

Когда нам нужно получить значение одного реквизита (например, ИНН контрагента или артикул товара), мы часто выбираем между тремя путями. Давайте сравним их, чтобы понять, какой подход соответствует стандартам 2026 года.

Метод	Как это выглядит в коде	Последствия для системы
Обращение «через точку»	`ContractorName = ObjectRef.Description;`	Плохо. Платформа неявно считывает из базы данных ВЕСЬ объект со всеми его табличными частями. Это создает избыточную нагрузку.
Классический запрос	`Query = New Query("SELECT Description FROM...");`	Громоздко. Нужно написать около 10-15 строк кода, создать объект запроса, выполнить его и выбрать результат.
API БСП	`ContractorName = Common.ObjectAttributeValue(ObjectRef, "Description");`	Идеально. Одна строка кода, минимальная нагрузка на сервер и автоматическая оптимизация.

В БСП для этого используется метод ЗначениеРеквизитаОбъекта (на латинице в коде — ObjectAttributeValue).

Инструмент №1: ЗначениеРеквизитаОбъекта

Метод ОбщегоНазначения.ЗначениеРеквизитаОбъекта() — это «швейцарский нож» для разработчика. Он позволяет получить данные объекта, не загружая сам объект в память сервера.

Как это работает: Мы передаем в функцию ссылку на объект и имя реквизита, который нам нужен. Система сама формирует максимально легкий SQL-запрос к базе данных и возвращает только конкретное значение.

// Получаем только дату документа, не загружая сам документ
DocumentDate = Common.ObjectAttributeValue(DocumentRef, "Date");

Инструмент №2: Чтение нескольких реквизитов сразу

Если нам нужно получить сразу три-четыре поля (например, ИНН, КПП и Полное наименование), вызывать функцию трижды — неэффективно. Для этого в БСП предусмотрен механизм работы со структурами.

Мы передаем строку с именами реквизитов через запятую, а на выходе получаем структуру, где ключи — это названия полей.

// Эффективное получение нескольких полей за один вызов
Attributes = "INN, KPP, FullName";
DataStruct = Common.ObjectAttributesValues(ContractorRef, Attributes);

ContractorINN = DataStruct.INN;

Кэширование данных: магия производительности

Одной из важнейших особенностей API БСП является встроенное Кэширование данных.

Когда мы запрашиваем реквизиты через стандартные методы, БСП может сохранять результат во временной памяти сервера (кэше). Если в рамках этого же сеанса нам снова понадобятся те же данные, система не будет обращаться к базе данных, а мгновенно возьмет их из памяти.

Это особенно актуально в облачных инфраструктурах, где каждое обращение к СУБД (Системе Управления Базами Данных) стоит времени и ресурсов.

Безопасное выполнение и стабильность

При написании прямых запросов легко совершить ошибку: например, не учесть, что ссылка может быть пустой или объект был удален. Это приведет к аварийному завершению работы программы.

Использование программного интерфейса БСП гарантирует нам Безопасное выполнение:

Проверка ссылок: Если передать в метод пустую ссылку, система не «упадет», а вернет Undefined (Неопределено) или пустое значение соответствующего типа.
Права доступа: Методы БСП учитывают настройки прав пользователя. Если у пользователя нет доступа к полю «Личный телефон», система корректно обработает этот момент без вывода системных ошибок.

Практические рекомендации

Чтобы наш код соответствовал уровню эксперта, мы придерживаемся правила:

Если нужно получить данные для одного конкретного объекта (или небольшого списка) — используем методы модуля ОбщегоНазначения.
Если нужно построить сложный отчет или выбрать данные по множеству условий — используем конструктор запросов.

Использование API вместо «точечных» запросов сокращает объем кода в среднем на 30-40%, делая его чище и понятнее для коллег.

Мы научились эффективно и безопасно извлекать данные из системы. Но что делать, если данных настолько много, что даже самый оптимизированный запрос заставляет пользователя ждать, глядя на «песочные часы»?

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