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

15 Січня 2019

наступна стаття
Олександр Марчак

Backend developer

Олександр Марчак
Впровадження служби доставлення boxberry. Підводні камені

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

Проект спеціалізувався на міжнародному доставленні товарів. І одного разу, вже майже на фінішній прямій, нам сказали замість поточної служби доставлення, для якої було вже все написано і працювало, впровадити і перевести весь функціонал на службу доставлення boxberry.

Сказано — зроблено

Приступили ми до роботи. Для початку потрібно було реалізувати обмін даними, додати в базу, регіони, склади і відділення, населені пункти та індекси, ну і подібну інформацію. Звичайно, щоб все було красиво прив'язано один до одного, по ієрархії, і налаштувати перевірку актуальності всіх вище перерахованих даних. І тут до нас непомітно підкрався, навіть не підводний камінь, а, я б сказав, цілий айсберг. Ним виявився API boxberry. Наприклад, ось перед Вами 1/843 їх частина.

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

Інформація в масивах була неповною. Наприклад, кількох регіонів РФ взагалі не було в списку цих самих регіонів. Самі назви регіонів / округів були де скорочені, а де й зовсім не повні. Через це довелося реалізовувати ще і «перекладач» для адаптування інформації. Нагадаю, що все повинно було бути автоматизовано. Назви регіонів, міст, населених пунктів — це взагалі окрема тема, якої торкнемося трохи нижче.

Але хоч би що там було з регіонами, все це тьмяніє і блідне перед звичайними населеними пунктами, або списком поштових індексів, якщо конкретніше.

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

Цей список, схоже, давався «людині на тому боці» особливо важко. Ну «його» можна зрозуміти: всього елементів було понад 65 тисяч. І жоден нічим не був пов'язаний, ні зі своїм регіоном, ні взагалі з будь-яким елементом, що могло повернути API — абсолютно самостійний, ні до чого не прив'язаний список з 65 тисяч міст.

Як ви вже здогадалися, це все потрібно було якось структурувати і внести в базу. Але оскільки прив'язок до коду регіону ніде не було (а все що було — це індекс, і в поспіху написана назва) довелося думати, як точно, а головне швидко, розсортувати ці пункти по регіонах. А як сучасний веб розробник вирішує складні завдання? Вірно — із застосуванням кмітливості та глобальної пошукової системи. Благо, на просторах Інтернету подібного роду інформації виявилося чимало. Незабаром ми знайшли більш-менш актуальний ХML документ зі списком індексів.

Далі, здавалося б, справа за малим: відпарсити документ, створити по ньому багатовимірний масив, і по ньому відфільтрувати згадану вище «незалежну державу». Але оскільки з документа масив вийшов асоціативним, причому з кириличними ключами, вийшло не все відразу.

І все запрацювало!

Ось ми і підібралися до вищезгаданої теми назв елементів. Так ось: всі зв'язки, які повертаються через API, були не по коду регіону або галузі, а просто по імені батька. А вже саме ім'я було не повним, типу «Московська» замість «Московська область», та ще й нерідко містило в собі латинські букви.

Наприклад, «а» була не кириличною, а латинською! І якщо для людини це не має значення, то для машинного коду проблема виявилася глобальною. Це все в підсумку ускладнювало сортування. Ми багато спілкувалися з представниками boxberry по ходу розробки. Благо, люди адекватно сприймали всі зауваження, і по ходу справи виправили безліч ось таких ось неприємностей. Тому якщо у вас буде подібна інтеграція, у виправленні помилок сервера значна заслуга команди Авіві.

Ще один невеликий «підводний камінчик» був в Тарифних зонах. Виявляється у boxberry, в порівнянні зі старою службою доставлення, в деяких містах їх могло бути більше, ніж одна. Через це були невеликі помилки з розрахунком вартості доставлення. Не відразу це помітили. Тому, як вище було сказано, що спочатку список тарифних зон формувався на підставі даних з попередньої служби доставки. І ми, вважаючи, що цей список є стандартом для всіх служб доставлення, спочатку здивувалися, як вартість доставлення однієї і тієї ж посилки, але в різні відділення одного міста, може відрізнятися один від одного. API boxberry звичайно дозволяло отримати розрахунок вартості доставки. Але оскільки у клієнта були на все власні тарифи, а бажання клієнта — закон, довелося підганяти все під нього.

Висновки

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

banner_ukr.png


Схожі статті

Записатись на консультацію

Ми зв'яжемось з Вами протягом 10 хвилин