Dobrý den, chtěl jsem se zeptat proč je u funkce GetMessageStateChanges přítomno omezení na rozsah prozkoumávaného období. Pokud jsem správně pochopil dokumentaci, tak GetMessageStateChanges vrací seznam zpráv s jejich stavem a časem přechodu do tohoto stavu v zadaném období pokud čas přechodu do stavu spadá do zadaného období A POKUD zadané období spadá do *** posledních 15-ti dnů ***. Když nebudu tuto funkci spouštět minimálně jednou za 14 dní, tak po delší pauze mi funkce vrátí prázdný seznam, i když u některých zpráv ke změně došlo - a totiž dříve než před 15ti dny. Tuto situaci nelze nikdy vyloučit, a proto nelze GetMessageStateChanges v mé aplikaci ( a věřím že nejen v mé ) vůbec použít a je nutné problém řešit "postaru" s daleko větším zatížením systému. Nedalo by se s tím něco dělat? Je pro zatížení systému vážně lepší, když se musí stahovat doručenka každé zprávy, než aby GetMesageStateChanges toto omezení nemělo? Dále myslím, že by bylo fajn kdyby funkce vracela i ostatní změny - tedy nejen ty, které jsou podstatné z procesního hlediska, ale i například změnu stavu zprávy do "smazaná" atd. Věřím, že s tímto požadavkem nejsem sám :-) Děkuji. Roman Krejčí.
145.1 Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36Dobrý den.
Služba GetMessageStateChanges funguje už 5 let a toto je za tu dobu první námět od vývojářů na změnu. Děkujeme za něj.
Služba je určena zejména pro velké schránky typu soud nebo ČSSZ, které mají tisíce zpráv denně, a jejich spisové aplikace běží nepřetržitě a službu volají alespoň denně. Pak je interval 14 dní dozadu dostatečný pro překlenutí nějakých problémů nebo odstávek. Rozšířit na 3 týdny by to jistě šlo, ale podle té vaší logiky by se stejně nic zásadního na použitelnosti nezměnilo.
Pokud nějaká schránka má tak málo zpráv, že se může přihlašovat méně než 1x za dva týdny, pak nemůže nijak znatelně zatížit systém a tato služba je dle našeho názoru pro ni zbytečná.
Co se týče přidání změny stavu na 9 (smazání) nebo 10 (trezor), s tím nepočítáme. Z hlediska práce aplikací, které si zprávy stahují k sobě, je smazání zprávy ze schránky nepotřebná informace (a trezor obvykle nemají, ze stejného důvodu, protože ty zprávy mají uloženy u sebe).
Jan Šíma
ISDS
145.2 Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36Děkuji za vysvětlení. Roman Krejčí.
145.3 Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36Ještě mne napadlo toto - pokud by se ony 2 týdny, po které je služba GetMessageStateChanges použitelná, protáhly na dobu, po které se stav mění na vymazaná nebo přesunutá do trezoru (to je teď těch 90 dní), tak by už GetMessageStateChanges šla velmi dobře použít. Zprávy, které by nezachytila, jednoduše stav nezměnily, nebo jsou už vymazané či přesunuté do trezoru. Bez ohledu na to, jak často tu službu bude aplikace volat. Roman Krejčí.
145.3.1 Re: Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36Dobrý den.
Bohužel ani lhůta 90 dní neřeší vše - existují zprávy, které jsou ve stavu Doručeno fikcí nebo Dodáno déle než 90 dnů - máme zprávy ještě z roku 2009.
Pořád ale nechápu, jaký je rozdíl pro aplikaci volat tu službu jedenkrát za 15 dní nebo jedenkrát za 90 dní.
Jan Šíma
ISDS
145.4 Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36To je zajímavá informace - jak může být zpráva ve stavu dodáno (stav 4) déle než 90 dní, když se po této době má buď mazat (stav 9) nebo přesouvat do trezoru (stav 10)? Asi mi není úplně jasný cyklus změn stavu zprávy. Dokumentace se bohužel nezabývá podrobným popisem podmínek pro změny dmMessageStatus z jedné hodnoty do druhé. Navíc mně trochu mate to, že zpráva může být ve stavu 10 (trezor) ale když ji stáhnu, tak deklaruje stav 6 - to už není v trezoru? Kde by se dal najít podrobný popis těch přechodů?
145.4.1 Re: Re: GetMessageStateChanges - nepoužitelné
admin 17.01.2017 11:36Dobrý den.
Zpráva se maže nebo přesouvá do DT 90 dní po doručení přihlášením (přechodu do stavu 6). Dokud není doručena přihlášením, tak se nemaže a je stále ve stavu 4 (dodána) nebo 5 (doručena fikcí). To je celé. To určitě napsané někde je.
Když stáhnete zprávu, která je v trezoru, tak se uloží do podepsaného XML formátu, a pro tento formát a aplikace, které jej zpracovávají je zcela jedno, jestli předtím někdy byla v trezoru nebo ne. Naopak podstatné je, z jakého stavu do trezoru spadla (6(7) nebo 8). To také napsáno někde je. Neříkám, že by to nešlo udělat jinak, ale Trezor byl novelou zákona přidán později, už za provozu ISDS a my jsme volili cestu sice trochu méně elegantní, ale zato zpětně kompatibilní, bez změny struktury datové zprávy, aby nemuseli všichni vývojáři přepisovat své aplikace za běhu.
Prostě pro zprávy v systému ISDS, prohlížené webovým Portálem, platí trochu jiná (výrazně složitější) logika než pro zprávy, které externí aplikace stahuje u ukládá k sobě.
s pozdravem
Jan Šíma
ISDS