Usability в корпоративных масштабах или UPS Freight API Example для тех кто не осилил

Как-то раз я интегрировал службу доставки UPS в один интернет-магазин.
Все было в порядке. Я использовал TimeInTransit API для получения времени доставки, Rates API для получения стоимости доставки, тихонько матюкался на то, что Fedex делает это в одном запросе. Но тем не менее все шло гладко. До тех пор, пока я не узнал, что через Rates API можно получить стоимость доставки только малогабаритных грузов. Для крупных грузов на TimeInTransit API, ни Rates API не работали.
Я поискал немного, и открыл для себя UPS Freight API — API для работы с тяжелыми грузами.

Сначала о том, как отличить тяжелый груз от нетяжелого:

Каковы вес и ограничения на размер груза UPS?

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

Вес пакета не должен превышать 150 фунтов (70 кг).
Вес пакета не должен превышать 165 дюймов (419 см) в длине и обхвате (в сумме).
Вес пакета не должен превышать 108 дюймов (270 см) в длину.

Источник на ups.com

Ок, без проблем. Я нашел пример кода и документацию по Freight API. К моему сожалению XML Webservice не поддерживается для нее, только SOAP.
С запуском примера из официального пакета скачанного с UPS у меня все незаладилось. Я перерыл и переввел все параметры, так что какой именно момент у них не работал точно сказать не могу. На основе их примера я сделал болванку класса для дальнейшего использования:
Болванка заработала. На основании болванки был сделан полноценный класс, возвращающий стоимость доставки по сервисам. Но почему-то не возвращающий время доставки… При этом документация UPS по этому поводу говорит:

Presence of the tag TimeInTransitIndicator indicates Time in Transit information is requested and will be returned.

То есть все, что нужно — это указать тег TimeInTransitIndicator. Тем не менее не смотря на наличие этого тега или его отсутствие ответ UPS API не изменяется — дней доставки в ответе нет. Своими силами этот вопрос так решить и не удалось. В сети удивительно мало вопросов и ответов по UPS APIs. Такое ощущение что о нем все забыли и им давно никто не пользуется. На этот раз мне не помог ни google, ни stackoverflow, ни форум UPS. Пришлось обращаться в саппорт, откуда был получен очень четкий ответ. Привожу его здесь без изменений:

Thank you for your inquiry. I apologize for the confusion with our Ground Freight Rating API and the <freightRate:TimeInTransit> element. The <freightRate:TimeInTransit> will only be returned when posting a request to the production URL. Your file is valid and I have tested with production approved credentials. I have attached the response file for your review and reference. Your key will need to be approved for production access for the Ground Freight Rating API before you will be able to post successfully to the production URL. The .xsd files and WSDL in the developer tool kit are designed to deliver this element in production without editing, so what you have observed with the schema files is by design.

Ребята из техподдержки также приложили типовой xml-ответ от production API:

И когда я думал, что муки мои кончились, я столкнулся с тем, что в запросе к UPS Freight API должны указываться Freight Class. Что такое Freight Class и какие должны быть в документации UPS не объясняется. <сарказм>Правильно ребята, правильно! Freight Classes должен знать каждый школьник!</сарказм> Так что пришлось поискать и их. По этой ссылке вы найдете список Freight Classes.

На этом мучения с UPS все еще не закончились, но перестали вмещаться в тему данной статьи. Если наберусь еще гнева, напишу и о них тоже.
Надеюсь кому то помог.
Не попадайтесь.

Полезно(8)Бесполезно(0)

Добавить комментарий