Vlákno názorů k článku Problémy u #EET nepřinesl život, ale špatně odvedená práce a ignorace připomínek od P2010 - Čistě po technické stránce to bylo taktéž nedomyšlené....

Čistě po technické stránce to bylo taktéž nedomyšlené. nicméně narozdíl od jiných ministerstev alespoň použili standardizovanou technologii WS-Security.

Rozhraní vůbec nepočitalo s chybami při komunikaci. Někdo od stolu vymyslel, že po chybě se transakce pošle znovu s příznakem "opakované zaslání", ale protože o tom samozřejmě nic nevěděl tak jim nedošlo, že takto nelze rozlišit chybu kdy komunikace selže již v požadavku (takže se nejedná o opakování) a kdy až při čekání na odpověď (pak se už jedná). V oficiální dokumentaci to mají stále tak nesmyslně popsané, jen v nějakém videozáznamu z konference přiznali, že ten příznak vůbec nepoužívají a případný opakovaný report stejné transakce ignorují aniž by to dali nějak vědět. Vrátí pro ni ale stejný FIK. Potíž je, že takto se chová pouze produkční rozhraní ale ne testovací, takže při vývoji nemáte žádnou možnost tento scénář odladit a ověřit, že tato neoficiální informace z nějakého videa (v dokumentaci to není) je pravdivá.

Hlavně že je za každou ztracenou transakci pokuta 500 000 Kč.

Tak, tak - nedomyšlené je značně slabé slovo.
A teď si představte, že máte tak 1 - 4 hotovostní platby měsíčně a kvůli tomu si pořídíte celý ten krám a vystavíte se případným sankcím za neúmyslnou chybu - tím spíš, že při této frekvenci hotovostních plateb s tím budete bojovat skoro pokaždé, protože budete v podstatě pořád začínat - takže pravděpodobnost, že uděláte banální chybu, bude větší...

Zatím moji fázi EET odložili, ale pak přestanu hotovost brát. Pořizovat si nějaké zařízení a platit měsíční poplatky kvůli několika tisícům za rok (<3% obratu) nehodlám.

Pokud tu 3.vlnu EET spustí udělám totéž.
Bohužel budu muset počítat s drobnými komplikacemi, které právě řešily hotovostní platby, a to mě nijak netěší.

Problém s chápáním psaného textu?

P2010 si nestěžuje, že to je špatné řešení. On si stěžuje, to není zdokumentované a že se to jinak chová na testovacím a produkčním systému. A tady samozřejmě lepší řešení nabídnout umí každý s IQ vyšším než ouřada - zdokumentovat to a implementovat to stejně na obou systémech.

To není. Robustní by to bylo, pokud by to vracelo příznak že šlo o opakované a tedy ignorované volání nebo by existovala druhá metoda, kterou by šlo ověřit, že je daná transakce již zpracována. Tahle je to jen nouzové řešení, kterým vybruslili z průšvihu daným vlastní neschopností.

Tato metoda má drobnou nevýhodu. Pokud nedošla odpověď z důvodu přetížení serveru/sítě, tak generuje další provoz, který situaci zhoršuje. A pokud odpověď nedošla z důvodu špatně naformátovaného requestu, tak to budete posílat až do konce věků a nikdy se nedozvíte, proč odpověď nepřichází. Takhle robustní řešení opravdu nevypadá.