<html><body>Viděl bych to takhle:<br>- Zákazník dostane shrnutí od serveru "Souhrn objednávky" s výpisem počtu stránek a dalších údajů, které vedly ke stanovení ceny a za tím cenu.<br>- Při realizaci objednávky budou údaje ze souhrnu použity jeko limit.<br><br>Takže když:<br>- server dostane data, která mají 1000 barevných stránek A2, ale cena bude stanovena pro 100 ČB stránek A6, objednávka se automaticky stornuje.<br><p>- server dostane data pro rozeslání 5000 obálek se stránkami A4, ale cena bude stanovena pro rozeslání 20 obálek se stránkami A4, vytiskne a pošle se 20 stránek a další zpraconání se zastaví, zákazník bude vyrozuměn, že data obsahovala 4980 stránek navíc oproti závazné objednávce, které nebyly rozeslánay.</p><p><br></p><p>PH<br></p><p><br></p><p>Od: RV <vicek.radek@cpost.cz><br></p><blockquote>Osvetlim o co se jedna...neni to tajne. Pripravujeme novou verzi nasi <br>aplikace Podatelna, ktera dokaze vyuzit nove API pro DopisOnline - tedy <br>muzete k nam poslat "libovolny" pocet PDF, u kazdeho urcit typ tisku, <br>oboustranne/jednostranne, poradi v obalce, data pro slozenku, vybrat <br>obalku, zda se adresa vezme textove, nebo vyrezem z prvniho PDF, poradi <br>PDF v obalce, postovne, specifikova dorucenku - tohle vse probehne na <br>urovni jednoho POST dotazu a odpovedi jsou podaci udaje, nejaky unikatni <br>identifikator a samozrejme i okamzite spoctena cena a nebo samozrejme <br>nejaky navratovy chybovy kod.<br><br>Doted to probiha tak, ze bud nas web nebo klientska aplikace sestavi XML <br>(v nem jsou zakodovany i vlastni data do BASE64) a preda je POSTem na <br>API bezici na serveru. Ten vytahne XML, rozparsuje ho, vytaha veskere <br>PDF a nasledne zacne parsovat tyto PDF zda splnuji pozadovane parametry <br>(orientace, zda nesjou sifrovane) a hlavne spocte pocty stranek a listu <br>(na zaklade toho zda se u toho PDF pozaduje jedno/oboustrnny text), <br>navic jeste provedeme zkusebni vyrezy (prevod do obrazku) adresniho okna <br>a provedeme castecnou analyzu zda tam neco je (setrime tim penize <br>zakazniku, kteri nejsou schopni napozicovat adresu nebo tam poslou <br>kravinu). Je to pomerne brutalni zaprah, kdyz si vezmete, ze se ceka <br>odpoved serveru obratem. Je to API takze opravdu multiobratkove rozhrani <br>- neni problem, aby od jednoho cloveka prislo 40.000 zasilek za hodinu. <br>Vcera jsem ten server otacel a vypada to tam nejak takhle:<br><br>Server uptime: 71 days 2 hours 11 minutes 12 seconds<br>Total accesses: 165622570 - Total Traffic: 11022.5 GB<br>27 requests/sec - 1.8 MB/second - 69.8 kB/request<br><br>tohle je jen otazka trafficu a pristupu (vsechno nejsou jen tyhle <br>prenosy - je v tom feedback), ale je treba videt za timhle i ten <br>vypocetni vykon na ty operace<br><br>Jedine data, kterym lze tedy verit a jsou zavazna, jsou predane XML se <br>zakodovanymi PDF.<br><br>Vzhledem k tomu, ze pomerne velkou cast objemu generuji uzivatele <br>pouzivajici nasi starou aplikaci, ktera byla pomerne tupa a neumi nove <br>ficury tak piseme novou. Je velmi lakave presunout vypocetni narocnost <br>na PC uzivatelu a provest validace, kontrolni vyrezy a dalsi veci na <br>strane uzivatele. A nasledne prenasene XML doplnit o jiz spoctene pocty <br>stran - navic odpadne hromada prenosu jiz tim, ze aplikace zjisti <br>nejakou chybu rovnou. Problem je to, ze kdyz nam nekdo bude podvrhovat <br>chybne pocty stran tak se budou chybne kalkulovat ceny - je na to <br>navazano cena za papir, tisk a i vaha zasilky a tedy postovne.<br><br>Resime tedy to jak se posychrovat, ze to je spravne a v pripade, ze <br>budeme komunikovat s nasi aplikaci tak API na serveru to bude propoustet <br>bez kontrol.</blockquote></body></html>