Мне довольно часто приходится общаться с техподдержкой 1С-Битрикс по работе. Время от времени находятся баги в ядре, которые мы не в силах устранить по той причине, что это бессмысленно. Бывают баги, на исследование которых могут уходить долгие часы, и искать их нерентабельно. Бывают иногда вопросы лицензионного характера, или вопросы по работе функционала с позиции пользователя. Но одно из последних обращений меня поразило «донельзя», чем хочу поделиться с Вами.
Предыстория
Началось все с того, что нам понадобилось с одним из заказчиков возобновить интеграцию между магазином, сделанным на 1С-Битрикс и CRM Битрикс24. Возобновить, потому что она у нас была где-то год назад, мы поднимали её для экспериментов, и какое-то время даже использовали совместно с облачной телефонией. В прошлый раз была проблема стыковки этих двух сайтов между собой, т.к. они были в разных кодировках. Тогда мне удалось решить проблему «по-быстрому», внеся один маленький фикс в ядро — при получении данных от магазина я хардкорно менял кодировку ответа от сайта, и все данные записывались в БД в нормальном виде. Но то было давно, заводили эту интеграцию исключительно для ознакомительных целей, поэтому я допустил саму возможность внесения такой правки. В прошлый раз CRM не прижилась и на это забили.
Но в этот раз все было по серьезному. Поэтому и проблему надо было решать «по-взрослому», а в данном случае через техподдержку, т.к. очевидно, что проблема в ядре.
Изначально я обнаружил два косяка:
- При первой синхронизации, которую битрикс обязывает провести, нужно указать период, за который загружать заказы с сайта в CRM. Там можно указать период в днях. Баг заключался в том, что эта настройка игнорировалась и загружались все заказы за всю историю.
- Собственно кодировка. Кириллические данные из заказов отображались в CRM в виде кракозябр.
Попутно обнаружилось еще пара менее значительных (которые, кстати, до сих пор не решены), но это уже другая история.
Ну ладно, думаю. Пойду в техподдержку решать вопрос.
И решил … Если кому-то интересен полный лог переписки, то можно посмотреть скрин с моими комментами
Если вкратце:
Проблема №1 решилась с помощью изменения языковых настроек языка «en». В каждом языке используется собственный формат даты. Так вот для того, чтобы интеграция между магазином и CRM работала корректно, необходимо, чтобы в настройках Английского языка была дата формата MM/DD/YYYY H:MI:SS T, и никакая другая.
Решение проблемы №2 затянулось. Сотрудники техподдержки обнаружили, что в момент обмена сайт выдает XML файл с заказами, где в первой строке присутствует не заголовок XML файла с описанием версии и кодировки, а простой перенос строки. Если посмотреть по исходникам модуля CRM, то видно, что при разборе XML (битриксы не полагаются в этом ни на какие библиотеки, а делают разбор сами на регулярках) модуль не может найти в первой строке кодировку файла, и пытается использовать ту, которая присутствует на проекте. Ок, решение очевидно — надо удалить пустую строку вначале XML файла, но для этого нужно найти, кто же её добавляет. Сотрудники техподдержки обнаружили, что если удалить директорию/local/php_interface/include/sale_payment/, в которой находятся пользовательские обработчики платёжек, то XML начинает формироваться корректно (забавно, они переименовывали эту директорию на рабочем проекте, и пока они проверяли функционал, ни одна платежная система на сайте не работала. На рабочем сайте, Карл! …. ).
Изучив исходники всех пользовательских платежных систем, не удалось обнаружить проблему. Но проблема нашлась там, где её искать было бесполезно — в стороннем модуле! Есть такой модуль — Купи ВКредит. Этот модуль дает возможность вместо оплаты оформить заявку на кредит, и он использовался в магазине. У него в файле /bitrix/modules/tcsbank.kupivkredit/payment/.description.php присутствовало 3 переноса строки после закрывающего php тега:
Если эти переносы строк удалить, то обмен работает корректно.
Как они там оказались? Ведь каждое решение проходит этап жесточайшей модерации.
Каким боком файл описания платежной системы участвует в формировании XML файла для выгрузки в CRM?
Почему мне пришлось раскапывать проблему через такие жуткие дебри? Ведь продукт платный, и включает в себя стоимость поддержки крутыми специалистами, которые должны в два счета решать такие проблемы.
Почему все так жутко и топорно реализовано? Никак не связанный функционал стороннего модуля влияет на стандартный изолированный функционал коробочной системы, в который при сильном желании-то влезть не получится?
Эти вопросы, судя по всему, так и будут витать в воздухе над битриксом … И ответов на них мы не дождемся никогда.
Суммарно на всю эту переписку и разрешение динамо-вопросов мне пришлось потратить около 8-ми часов, начиная от постановки и заканчивая решением. Жаль этого времени, на самом деле. Мог бы потратить его с бОльшей пользой.
Выводы
- Техподдержка очень любит динамить не по делу, постоянно стараясь отсрочить решение проблемы.
- Техподдержка делает изменения на проде без вашего контроля, которые могут повалить сайт или отрубить часть его функциональности ненамеренно.
- Стоит версионировать ядро хотя бы для того, чтобы контролировать изменения техподдержки в коде, чтобы потом предъявить
P.S. Немного статистики
Я тут подсчитал на досуге. В модуле support, который используется в техподдержке битрикса для трекинга обращений, все обращения хранятся в таблице с обычным автоинкрементом. Обращение, о котором идет речь в посте, имеет порядковый номер 1648523 и было создано 13го сентября 2017 года. Мое первое обращение в техподдержку битрикс имело порядковый номер 246022 и было создано 6 октября 2011 года. Т.е. за 6 лет битрикс принял около 1.4 млн обращений. В среднем это получается 233к обращений в год. Или 640 обращений в день (в любой день, даже в выходные и праздники). Я не знаю, насколько много сотрудников в отделе техподдержки, но даже если у них там 20 сотрудников, то это 32 обращения в день в среднем за 6 лет, и это без учета динамики! А если учесть динамику (тут у меня недостаточно данных, конечно), то я думаю, что они обрабатывают сейчас все 1000 обращений в день, и даже может быть больше. Не завидую я этим ребятам, и с одной стороны я могу понять, почему они динамят всех и вся.
Но как сказал один мудрец:
Нормально делай — Нормально будет!
Убежден, что можно снизить нагрузку на техподдержку в разы, если делать продукт по человечески, а не обманывать население пустыми обещаниями и золотыми горами. В итоге улучшение качества продукта привело бы уменьшению трудозатрат сотен, тысяч людей по всей стране, а это дорогого стоит.
P.P.S. Немного поржать
Нет, я все понимаю, есть компании, которые могут позволить себе прикалываться и «угарать» публично. Как правило — это гиганты типа google, facebook, yandex, etc. Но если они это делают, то они это делают качественно, это выглядит весело со стороны.
Видимо, в техподдержке битрикса считают вот эти видосы прикольными. Но для меня лично они дают ответы на многие вопросы, которые я задавал себе о битриксоидах. Смотрим:
