Почему при сборке мобильного приложения возникает ошибка доступа к журналу регистрации и как её исправить?

При разработке мобильных решений на платформе 1С разработчики нередко сталкиваются с тем, что конфигурация, успешно работающая в клиент-серверном варианте, выдает критические ошибки при попытке сборки мобильного приложения. Одной из наиболее частых проблем является сообщение о том, что переменная УровеньЖурналаРегистрации или функция ЗаписьЖурналаРегистрации не определены. Давайте разберем, почему это происходит и как правильно адаптировать код.

Понимание архитектурных ограничений

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

Мы должны понимать следующие моменты:

1. Мобильное приложение (автономное): Работает на мобильной платформе без полноценного сервера 1С. Здесь отсутствует функционал ЖурналРегистрации, так как он является серверным механизмом.
2. Мобильный клиент: Представляет собой «тонкий» клиент, подключающийся к удаленному серверу. В этом случае серверный контекст доступен, и запись в журнал может выполняться на стороне сервера 1С.

Когда мы пытаемся собрать автономное приложение, система контроля целостности конфигурации проверяет доступность методов. Поскольку ЗаписьЖурналаРегистрации не поддерживается мобильной платформой, сборка прерывается с ошибкой.

Как решить проблему с помощью директив препроцессора

Самый эффективный и правильный способ «объяснить» платформе, что определенные куски кода не предназначены для выполнения в мобильном окружении — использование директив препроцессора. Это позволяет исключить выполнение кода на этапе компиляции.

Рассмотрим, как спрятать вызов ЗаписьЖурналаРегистрации от мобильной платформы:

#Если Не МобильноеПриложениеКлиент Тогда
    ЗаписьЖурналаРегистрации(Событие, УровеньЖурналаРегистрации.Ошибка, ...);
#КонецЕсли

При использовании такой конструкции, при сборке мобильного приложения компилятор просто «вырежет» данный блок кода, и ошибка исчезнет. Если же нам необходимо выполнить какое-то действие только на клиенте, мы можем использовать обратную логику.

Рекомендации по проверке кода

Чтобы не дожидаться финальной стадии сборки (которая может занимать много времени), давайте разберем, как проверять проект на лету:

1. Инструменты Конфигуратора: Используйте функцию «Проверка конфигурации» (меню «Конфигурация» -> «Проверка конфигурации»). В настройках обязательно активируйте проверку для мобильного приложения.
2. Синтакс-помощник: Всегда обращайте внимание на раздел «Доступность». Если метод не имеет пометки Мобильное приложение (клиент), использовать его напрямую в коде приложения нельзя.
3. Локализация ошибок: Если метод не поддерживается, нет смысла пытаться «заставить» его работать. Необходимо либо полностью убирать такие вызовы, либо оборачивать их в условия проверки контекста исполнения.

Альтернативные способы логирования в мобильном приложении

Поскольку встроенный ЖурналРегистрации недоступен, нам нужно организовать альтернативную систему сбора логов, если это критически важно для бизнес-задачи. Рассмотрим три популярных подхода:

• Файловое логирование: Используйте объект ЗаписьТекста для создания текстовых файлов в локальной директории устройства. Это самый простой способ сохранения истории действий пользователя.
• Собственный регистр: Создайте справочник или регистр сведений, куда вы будете записывать ошибки. При успешной синхронизации с сервером вы можете предусмотреть механизм выгрузки данных логов на основную базу.
• Внешние API: Если приложение работает через интернет, можно отправлять ошибки на внешний сервис сбора логов (через HTTPЗапрос).

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