Заказать проект
Оставьте заявку для получения коммерческого предложения.
Заполните форму и мы вышлем Вам предложение в котором решим,
чем можем вам помочь.
Внедрение службы доставки boxberry. Подводные камни

Внедрение службы доставки boxberry. Подводные камни

15 Января 2019
Александр Марчак
Backend developer
Александр Марчак
следующая статья

Жил да был один проект. Сказать что проект был интересный — ничего не сказать. Было в нем все: своя архитектура, собственное API, интересные задачи, и не менее интересные проблемы, за которыми хотелось сидеть и просто их решать. Хотя иногда возникало и желание начисто отформатировать диск с проектом, но все это — рабочие моменты на пути к удовлетворению потребностей клиента.

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

Сказано — сделано

Приступили мы к работе. Для начала нужно было реализовать обмен данными, добавить в базу, регионы, склады и отделения, населенные пункты и индексы, ну и тому подобную информацию. Естественно, чтобы все было красиво привязано друг к другу, по иерархии, и настроить проверку актуальности всех  выше перечисленных данных. И тут к нам незаметно подкрался, даже не подводный камень, а, я бы сказал, целый айсберг. Ним оказался API boxberry. К примеру, вот перед Вами 1/843 их часть.

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

Информация в массивах была не полной. К примеру нескольких регионов РФ вообще не было в списке этих самых регионов. Сами названия регионов/округов были где сокращенные, а где и вовсе не полные. Из-за этого пришлось реализовывать еще и “переводчик” для адаптирования информации. Напомню, что все должно было быть автоматизировано. Названия регионов, городов, населенных пунктов — это вообще отдельная тема, которой коснемся чуть ниже.

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

Привязка населенных пунктов

Этот список, похоже было, давался “человеку на той стороне”, особенно тяжело. Ну “его” можно понять: всего элементов было чуть больше 65 тысяч. И ни один ничем не был связан, ни со своим регионом, ни вообще с каким либо элементом, что могло вернуть API — абсолютно самостоятельный, ни к чему не привязанный список из 65 тысяч городов.

Как вы уже догадались, это все нужно было как-то структурировать и внести в базу. Но так как привязок к коду региона нигде не было (а все что было это индекс, и в спешке написанное название) пришлось думать, как точно, а главное быстро, рассортировать эти пункты по регионам. А как современный веб разработчик решает сложные задачи? Верно — с применением смекалки и глобальной поисковой системы. Благо, на просторах Интернета подобного рода информации оказалось немало. Вскоре мы нашли более-менее актуальный хml документ со списком индексов.

Далее, казалось бы, дело за малым: отпарсить документ, создать по нему многомерный  массив, и по нему отфильтровать упомянутое выше “независимое государство”. Но так как из документа массив получился ассоциативным, причем с кириллическими ключами, — получилось не все сразу.

И все заработало!

Вот мы и подобрались к вышеупомянутой теме названий элементов. Так вот: все связи, возвращаемые через API, были не по коду региона или области, а просто по имени родителя. А уже само имя было не полным, типа “Московская” вместо “Московская область”, да еще и нередко содержало в себе латинские буквы.

К примеру,  “а” была не кириллической, а латинской! И если для человека это не имеет значения, то для машинного кода проблема оказалась глобальной. Это все в итоге затрудняло сортировку. Мы много общались с представителями boxberry по ходу разработки. Благо, люди адекватно воспринимали все замечания, и по ходу дела исправили множество вот таких вот неприятностей. Поэтому если у вас будет подобная интеграция, в исправлении ошибок сервера значительная заслуга команды Авиви.

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

Выводы

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

Need help?

Ask a question.

Chat Now
Записаться На Консультацию
Записаться На Консультацию
Мы свяжемся
с вами
в течении
10 минут
laptop
Мы свяжемся с вами в течении 10 минут