myAPI ukončeno

[Rndoom04]

PPL již MyAPI nepodporuje, provoz neschválí. Přešli na CPL - API. Štítky už generují na své straně.

[Salamek]

Nejaka dokumentace/oznameni k tomu je?

[Rndoom04]

Oficiálně venku jsem ji nenašel. Poslalo mi ji PPL po mé žádosti, ale není tam nic tajného, přikládám. Je potřeba si u nich vyžádat credentials na dev.
PPLCPL.pdf

EDIT: Zjistil jsem to při integraci MyAPI. Poslal jsem jim ke schválení štítek v PDF a odepsali mi, že to schválit už nemohou, že začnou podporovat všem novým žádostem už jen CPL. Co bude s MyAPI nevím, ale předpokládám, že už se udržovat nebude. Výhodou CPL je ještě to, že číselné řady si hlídají oni.

[Salamek]

Konecne jim doslo ze by si ciselne rady meli spravovat sami a generovat etikety na sve strane... (presneji je asi donutilo DHL po tom co videli ten MyApi bordel) a misto SOAP pouzivaji REST. No smrti MyApi mi lito nebude :-D

[jan-kratochvil]

Už to někdo používá v ostrém provozu, nebo je to jen beta? Jsem dlouholetým uživatelem myApi a zatím jsem žádnou zprávu z jejich strany nedostal.

[Rndoom04]

Už to někdo používá v ostrém provozu, nebo je to jen beta? Jsem dlouholetým uživatelem myApi a zatím jsem žádnou zprávu z jejich strany nedostal.

Informovanost z jejich strany je stejně příšerná, jako podpora na chatu. Když už se člověk dopíše nebo má kontakt přímo na IT, už je to lepší... Člověk jim položí 3 otázky, aby si ušetřil čas sobě i jim a oni odpoví jen na jednu otázku a ještě tak, na co se člověk neptal. :) Dokumentace si člověk musí vyžádat a i tak mu nepošlou všechny. Mají hromadu PDFek a když to konkrétně nehledáš, asi to ani nedostaneš. CPL u pár klientů už využívám, protože nám myAPI neschválili a novým zákazníkům ani neschválí - info z jejich strany. Vypadá to ale, že to asi funguje. Jen teda mají stále trapně vyřešený výběr služby - musí pro to programátor udělat nějaké mapování - parcel shop/na adresu vs. bez dobírky/dobírka vs. stát. Reálně pro zákazníka, co využívá 2 státy musím mapovat 8 služeb. Je to sice maličkost, ale úplně zbytečná. A to neřešíme ještě vratky a další věci. Další úplná kravina je, že data z CPL se nepropíšou do zákaznické sekce a odkazují na to, že si máme postavit vlastního správce. No, to v případě integrace je snad samozřejmost, ale občas zákazník chce jít do jejich sekce, aby zjistil, jestli není někde nějaký problém, udělat nějakou kontrolu, atp. no a musí na to mít speciální login... Navíc u doprav mimo ČR se nepropisuje tel. číslo na štítek.

Až bude někdo vyvíjet veřejnou knihovnu, přeji úpřímnou soustrast, protože každou chvíli je dev API nedostupné a člověk tak marně hledá chybu na své straně. :)

[Rndoom04]

A ještě doplním zážitek. DOPORUČUJI si ukládat všechna čísla - IDčka požadavků i referenční čísla a i v případě neúspěšného volání raději poslat request na storno. Na TESTOVACÍ CREDENTIALS jsem objednal svoz a druhý den si pro něj chtěli jet... Neměl jsem ho jak stornovat, protože to bylo přes referenční číslo, které jsem při debugu generoval jako uniqid() no a prostě z žádného volání jsem ho nedostal, protože ty testovací credentials jsou společné pro víc vývojářů. Před vývojem mi psali, že si mohu volat jak chci co chci a nemusím se obávat, že by si pro to někdo přijel nebo bych něco platil...

[Salamek]

@Rndoom04
Kdyz jsou testovaci credentials shared, vadilo by ti mi je sharnout na mail? (lamat je z PPL se mi moc nechce :-D)

[Rndoom04]

@Rndoom04 Kdyz jsou testovaci credentials shared, vadilo by ti mi je sharnout na mail? (lamat je z PPL se mi moc nechce :-D)

Napsal jsem to trochu nešťastně a nechci šířit bludy. :D Credentials jsou dejme tomu pro každého zvlášť asi (aspoň mi to tak přijde dle identifikátoru, který se skládá z iniciálů mého jména). Data, ke kterým se díky nim dostaneš jsou už pak shared. Zkus jim napsat na integration@ppl.cz, údaje mi dali do druhého dne.

[radek3911]

Tak já už mám jedno produkční spuštění za sebou. API je celkem stable a docela jednoduché na použítí.
Samozřejmě mapování služeb je trochu horší, ale to se dalo jednoduše převzít ještě z MyApi.

Jedna fatální chyba však proběhla: zapomněl jsem vypnout dev mode a zákazník omylem vyexpedoval některé testovací štítky. Ty PPL pak vrátilo, ale mezitím to nabouralo číselné řady MyApi - ano testovací štítky PPL systém naskenoval i když je neměl v systému a přiřadil podle číselné řady nějakému jinému zákazníkovi. (No co už stane se, chyba hlavně na mojí straně). Tady je ale každopádně prostor pro zlepšení - jediný způsob jak poznat testovací štítek je, že má nahoře adresu www.HF.ppl.cz, například DPD na druhou stranu napíše přes půlku štítku TEST !!! a www.HF.ppl.cz si málokdo všimne ze zaměstnanců, kteří např. expedují objednávky.

Co se týče API, tak je fajn sledování balíků, obsahuje dokonce i balíky z MyApi, takže tam je to bez problémů.

Nejvíc mě asi štve způsob jak se štítky tisknou, teď je tiskne PPL ale přes batche, všichni ostatní dopravci jsou schopni vrátit štítek on-demand ale PPL po odeslání dávky štítek začně připravovat, zpravidla je to u 1 balíků v dávce do 3-4s což je v pohodě čas, pokud je tam ale víc balíků, nebo více kusových zásilek tak to může trvat klidně až minutu (podle počtu).

To má PPL ale "dobře" vyřešený - pošlou Vám email nebo nahrají to na FTP jakmile to bude hotové, FTP mi vůbec nefungovalo a e-mail sice přišel ale není to ideální řešení. Nezbylo mi nic jiného než tedy sleep a while (ano jsou lepší způsoby, ale pro mojí implementaci jsem potřeboval štítek hned tak jsem to nechtěl komplikovat cronem či nějakým jobem).

Škoda když už mají REST API, že je však nenapadl ten nejjednodušší způsob, místo FTP a emailu mohli udělat webhook, ten mi příjde jako nejvíc praktický a hlavně by to odpovídalo tomu REST API designu, ke kterému směřují.

Dále co se týče tisku štítků, tak jsou "OK", ale jsou vytištěné tak trochu divně, je to spíš obrázek, který printnuli do PDF, takže text v PDF nebude, kvalita štítků docela OK, testováno s Zebra ZD230 (PDF) i (ZPL). V CPL je však nezdokumentovaný page size - jsou 2 buď Default (což je +- A6 formát) a pak A4 (A4).

Každopádně jinak komunikace s PPL kolem API za mě dobrá, snažili se poradit když mohli a schválení a uvedení do produkčního provozu proběhlo rychle (v rámci 1 týdne).

Největší výhoda je pak samozřejmě, že nemusím řešit vůbec číselné řady, což bylo docela peklo a zodpovědnost.

[szymsza]

Pokud někdo najde tenhle balíček a mrzí ho, že už nefunguje (jako mě), vytvořil jsem jednoduchý balíček na napojení na nové API:
https://github.com/szymsza/php-ppl-create-package-label-api

Balíček za vás vyřeší autentizaci a jsou tam příklady častých use cases.

[Salamek]

@szymsza to je jednoducha impl. ale urcite lepsi nez nic (pro dokonalost by to chtelo ty enumy a modely a asi i ZPL label generator pokud ho PPL nepodporuje... 🤷 ) ale chapu ze kdo se s tim ma parat kdyz toho vic nepotrebuje 😄 GJ

[AlexKratky]

Pokud by někdo řešil implementaci CPL API v Laravelu, může využít https://github.com/bohemicastudio/ppl-myapi . Umožnuje vytvoření zásilky v jejich systému a stažení PDF labelu + snadné stahování dat z jejich enumu (codelist). Nechtěli jsme tam přidávat vícero funkcí, protože sami je nevyužíváme a enumy jsou z části proměnlivé, takže jsme je tam nepřidávali konstantě, s výjimkou enumu produktů (služeb).