Работа в облачном сервисе 1С:Фреш привлекает пользователей автоматическими обновлениями, отсутствием необходимости содержать собственный сервер и возможностью работать из любой точки мира. Однако иногда автоматическое обновление может преподнести неприятный сюрприз. Представим ситуацию: ваша база обновилась до нового тестового релиза (например, 3.0.69.27), и внезапно ключевые рабочие инструменты — отчет «Кассовая книга» и интеграция со Сбербанком — полностью перестали функционировать. В этой статье мы подробно разберем, почему происходят такие сбои, как устроена архитектура обновлений в облаке, и какими путями можно решить возникшие проблемы.
Когда в локальной (коробочной) версии программы происходит неудачное обновление, системный администратор или сам пользователь может легко восстановить базу данных из резервной копии, сделанной перед обновлением. В облаке 1С:Фреш этот привычный механизм не работает. Давайте проанализируем, почему так происходит.
Сервис разработан на основе технологии мультиарендности (Multi-tenancy). Это означает следующее:
Таким образом, единственным выходом в облачной среде является исправление ошибок «на лету» с помощью оперативного выпуска хотфиксов (исправляющих патчей) или новых микро-релизов разработчиками фирмы «1С».
Многие пользователи задаются вопросом: почему их стабильно работающая база вдруг обновилась на тестовый, еще не проверенный до конца релиз? Фирма «1С» использует практику так называемых «пилотных зон» (тестовых кластеров). Новые версии программ обкатываются на реальных базах данных ограниченного круга пользователей сервиса. Это позволяет собрать статистику редких ошибок, которые невозможно смоделировать в условиях синтетических тестов в лаборатории.
Попасть в пилотную зону пользователи могут как по собственному желанию (через обращение к обслуживающему партнеру для тестирования новых функций), так и автоматически, если их база распределена на серверы, выделенные под пилотное развертывание. Если вы столкнулись с обилием критических ошибок, обязательно известите службу технической поддержки сервиса. Чем быстрее разработчики получат отчеты об ошибках (лог-файлы), тем быстрее выйдет исправляющий патч.
В релизе 3.0.69.27 при попытке сформировать отчет «Кассовая книга» пользователи массово сталкивались с критической ошибкой встроенного языка. Программа аварийно завершала работу. Причиной послужила техническая опечатка разработчиков в коде формирования печатных форм и компоновки данных.
Поскольку кассовые операции требуют ежедневного контроля, фирма «1С» оперативно отреагировала на проблему, выпустив хотфикс в составе релиза 3.0.69.32. В этой версии работа отчета была полностью восстановлена. Для пользователей облака исправление применилось автоматически в ночное время, не требуя никаких ручных манипуляций.
Вторая проблема оказалась глубже и была связана с аппаратными токенами шифрования Сбербанка. При попытке выполнить обмен документами система выдавала ошибку авторизации. Разберем техническую суть этой ошибки.
Аппаратные USB-токены Сбербанка с новой версией встроенного программного обеспечения (прошивка 505) при выполнении криптографической процедуры аутентификации возвращали специальный параметр — подпись соли. Особенность новой прошивки заключалась в том, что в конце этой строки токен добавлял невидимые управляющие символы переноса строки: перевод строки \n и возврат каретки \r.
Встроенный код 1С в общем модуле ОбменСБанкамиСлужебныйКлиент принимал эту строку и передавал её во внешнюю компоненту Сбербанка «как есть». Из-за наличия лишних скрытых символов компонента не могла корректно сопоставить хэш-суммы и возвращала ошибку аутентификации.
Давайте рассмотрим, как выглядит программное решение этой проблемы на уровне кода 1С. Для исправления ситуации необходимо принудительно очистить возвращаемую строку от управляющих символов.
В процедуре ПровестиАутентификациюПослеПолученияФродПараметровСбербанк общего модуля ОбменСБанкамиСлужебныйКлиент исходный код вызова аутентификации выглядел следующим образом:
ДополнительныеПараметры.ПодключаемыйМодуль1С.НачатьВызовАутентификация(
Оповещение,
ДополнительныеПараметры.ИдентификаторСессии,
ДополнительныеПараметры.ПодписьСоли,
ДополнительныеПараметры.СтрокаФрод,
ИдентификаторСессии,
КодВозврата
);
Чтобы обойти ошибку прошивки 505, разработчикам (или программистам локальных версий) потребовалось заменить этот фрагмент кода на более безопасную обработку строки с использованием функции СтрЗаменить:
// Очищаем подпись соли от невидимых символов перевода строки и возврата каретки
ПодписьСоли = СтрЗаменить(СтрЗаменить(ДополнительныеПараметры.ПодписьСоли, Символы.ПС, ""), Символы.ВК, "");
ДополнительныеПараметры.ПодключаемыйМодуль1С.НачатьВызовАутентификация(
Оповещение,
ДополнительныеПараметры.ИдентификаторСессии,
ПодписьСоли,
ДополнительныеПараметры.СтрокаФрод,
ИдентификаторСессии,
КодВозврата
);
Этот простой прием позволяет полностью нейтрализовать влияние особенностей прошивки токена. В облачном сервисе 1С:Фреш пользователи не могут редактировать общий код конфигурации самостоятельно. Официальное исправление этой ошибки вместе с обновленной внешней компонентой Сбербанка (версии 1.2.9.1 и выше) было окончательно включено в стабильный релиз 3.0.70.39.
Описанные выше сложности с версиями прошивок токенов, установкой локальных драйверов защиты и внешних компонент (таких как VPN-key-TLS) со временем подтолкнули разработчиков к кардинальному улучшению интеграции.
Сегодня Сбербанк и фирма «1С» полностью перешли на современную технологию прямого обмена — Sber API в рамках технологии 1С:ДиректБанк. Старый шлюз обмена (УПШ), требовавший сложной локальной настройки шифрования на компьютере пользователя, выведен из эксплуатации.
Современный обмен по технологии Sber API обладает рядом преимуществ:
Если вы до сих пор используете устаревшие механизмы обмена через промежуточные файлы или старые утилиты шифрования Сбербанка, настоятельно рекомендуем выполнить настройку интеграции через «1С:ДиректБанк». Это раз и навсегда застрахует вашу компанию от подобных технических сбоев при последующих обновлениях облачной бухгалтерии.