Откуда не ждали: неочевидные ошибки, которые возникают при переходе на российское ПО. Часть 2

Руководитель практики ИТ и сервисов ALP Group Валерий Лямо продолжает рассказывать, на каких, казалось бы, мелочах спотыкаются большие импортонезависимые системы и как избежать подобных ошибок.

В прошлой статье я рассказывал об ошибках пользователей, которые нередко всплывают в процессе перехода на импортонезависимые системы. Но порой проблемы кроются и в самой платформе…

1. Разные регистры букв.

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

Но дальше нас ждала куда более серьёзная проблема — BI-система не видела исторические данные, загруженные ранее. Представьте: вы хотите оценить, например, трудозатраты сотрудников; BI-система анализирует базу данных и показывает отчет только за сегодня — все показатели по старым учетным периодам испарились, как будто до сегодняшнего дня в компании вообще никто не работал.

Мы долго бились, пока не обнаружили, что данная BI-система чувствительна к регистру символов ID объектов и для нее “91bf0050560118ed11ec5f348a440a01” и “91BF0050560118ED11EC5F348A440A01” — это разные сущности. Всё бы ничего, вот только при загрузке в Postgres Pro идентификаторы объектов во всех справочниках и документах были автоматически преобразованы из верхнего регистра (стандарт Microsoft SQL) в нижний. В результате BI-система не могла «склеить» данные по идентификаторам и просто не видела связи между старой и новой информацией. Мы поправили регистры — и еще одна проблема оказалась решена.

2. «Целое вне диапазона».

При тестировании функционала в импортонезависимом окружении наши консультанты начали полностью прогонять возможные пользовательские сценарии. Вдруг документы перестали проводиться, и всплыла невнятная ошибка: «Целое вне диапазона». Какое целое? Какого диапазона? Ясно, что ничего не ясно…

Мы настроили аналогичный набор прав в Windows-среде, и при выполнении той же операции получили теперь уже вразумительную ошибку: «У пользователя недостаточно прав на исполнение операции над базой данных». Вот теперь всё ясно: для данного воображаемого пользователя в системе стоят ограничения доступа на уровне записей (RLS), и «пользователь» (наш консультант) пробует работать с таблицами, на которые у него нет прав. Корректная настройка профилей/групп доступа пользователя в базе с импортонезависимым окружением моментально решила проблему.

3. Некорректная обработка исключений.

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

Когда мы начали тестировать эту функцию в Linux, то заметили, что команда «ВызватьИсключение» отрабатывается некорректно. При срабатывании команды происходит зависание фонового задания, что приводит к невозможности входа в конфигуратор базы данных системы. Пришлось без малого переписывать код, чтобы исключить запуск команды «ВызватьИсключение» в рамках работы фонового задания, и только после этого проблема была решена.

4. NULL.

Еще одну занятную особенность поведения платформы в работе с разными СУБД мы заметили при сортировке в запросах по полям со значением NULL, которое символизирует отсутствие данных. В Microsoft SQL все такие поля автоматически отправляются в конец таблицы, а в Postgres Pro они по умолчанию вылетают на самый верх. В нашем случае речь шла о таблице, из которой извлекались задачи в очередь на выполнение — они должны были ранжироваться по убыванию приоритета (число), и первая задача с наивысшим приоритетом шла в обработку. Как вы понимаете, в Postgres Pro этой сверхважной задачей стал… NULL.

Чтобы «пофиксить» проблему, нам пришлось вычистить значения NULL из результатов с помощью конструкции ЕСТЬNULL, чтобы унифицировать работу системы и получать корректный результат вне зависимости от используемой СУБД. Все подобные поля стали улетать вниз не только в Microsoft SQL, но и в Postgres Pro.

* * *

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

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

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