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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновки

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