1. V ramci implementacie AIS boli vytvorene automaticke joby na odosielanie DZ. Job sekvencne odosiela jednotlive spravy. Akutalne odosielame asi 90% sprav uplne v poriadku. U niektorych sprav vsak nastava problem pri citani odpovede.
Podla nasich logov nie je uplne jasne v com je problem. Zda sa ako keby mohli nastavat 2-3 rozne pripady:
· WS client HTTP odpoved dostane, ale je uplne prazda. Z toho dovodu nie su spravne detekovane headre a spracovanie samozrejme nedopadne OK.
· WS client ostane cakat pri citani zo socketu. V tomto pripade uz nevieme uplne presne oddelit 2 moznosti:
1. WS client sa snazi ziskat ako prvu informaciu z response HTTP kod. Uz pri jeho ziskavani caka (viac ako 10minut) na socketRead.
2. Existuje moznost, ze by uz v ramci odosielania spravy z nasej strany prestali servre komunikovat a nas client caka na potvrdenie zo vzdialenej strany?
Ako som uz pisal vacsina sprav prechadza uplne OK. Navyse spravy, ktore sa nam nepodarilo odoslat sme skusali znova aplikacne preposlat. Napr. v dnesnom pokuse sa nam podarilo odoslat uplne vsetky spravy.
Napada nas preto, ci nemoze existovat nejake technicke obmedzenie na pocet/velkost sprav v TST prostredi ISDS. Napr:
· Aplikacne
o napr. server v ramci ochrany pred pretazenim prestane odpovedat na WS volania, ak prislo v priebehu nejakeho casoveho useku viac ako X sprav?
o Sprava nemoze byt vacsia ako XX kb. (Najvacsie nase spravy by mali mat priblizne ~150kb)
· Sietove – nejaky kus infrastruktury (firewall) zacne zahadzovat packety v pripade, ze zdetekuje prilis vela opakujucich sa spojeni?
Snazili sme sa rovnako skontrolovat vystupny stream z nasej aplikacie. Vdaka HTTPS sa nam to ale nepodarilo. Je mozne niekde zavolat ISDS iba cez protokol HTTPS?
2. Rovnako by sme sa chceli opytat, ci k rozhraniu na TST prostredi existuje este nejaka rozsirena dokumentacia.
V dokumentacii, ktoru sme obdrzali napr. nie su popisane ciselne kody chybovych stavov pre volanie createMessage. (Zatial sa nam z logov podarilo rekonstruovat niekolko textovych popisov k obdrzanym chybovym kodom. Urcite ale nejde o kompletny list.)
45.1 Re: Chyba v komunikaci s ISDS (automat)
admin 23.01.2017 08:59Dobrý den.
Žádné technické systémové omezení provozu v ISDS dnes není.
Popisujete zřejmě rozpad spojení - pokud dokážete identifikovat nějaký požadavek, který dopadl špatně (co nejpřesnější čas, číslo zprávy nebo ID schránky odesílatele apod.), můžeme jej nalézt v našem logu a dozvědět se víc. A hlavně v jakém prostředí - test nebo produkce.
Číselník chyb je ke stažení a tomto webu v části ...\Testovací prostředí\Dokumentace a formuláře.
Jan Šíma
45.1.1 Re: Re: Chyba v komunikaci s ISDS (automat)
admin 23.01.2017 08:59 Attachments: chybnyAdresat.txt, neodoslanaISDS.txt, neodoslanaISDS2.txtDěkuji za odpověď. Předávám info od kolegů.
V prilohe posielam 3 pripady, kedy nam ISDS spadli s chybou. V kazdom file je na prvom riadku priblizny cas, kedy sme spravu posielali. (cas je priblizny, pretoze je to cas zalogovania spravy. Skutocne odoslanie by malo byt par milisekund po logu.)
· neodoslanaISDS.txt – jedna starsia sprava
· chybnyAdresat.txt (odoslane dnes) – tu je zamerne chybny adresat. Co je samo o sebe chybou, kazdopadne ISDS mali odpovedat chybovym stavom. Namiesto toho, sme ale odpoved nedostali vobec.
· neodoslanaISDS2.txt (odoslane dnes) – tento adresat je spravny, no rovnako sme nedostali dopoved.
Spravy sme odosielali z DEV prostredia, ktore je pripojene na https://ws1.czebox.cz/DS/dz
45.2 Re: Chyba v komunikaci s ISDS (automat)
admin 23.01.2017 08:59Dobrý den.
Potřebovali bychom hlavně ID schránky odesílatele a ID uživatele, pod nímž to bylo odesíláno, abychom ty požadavky mohli identfikovat.Já se s Vámi spojím emailem.
Jan Šíma
45.3 Re: Chyba v komunikaci s ISDS (automat)
admin 23.01.2017 08:59Dobrý den.
Podle logů vidíme velký traffic z Vaší strany, ale nic špatného. Třeba ten Váš request z 13:51:23,515 máme v logu v 23,542, v 23,548 backend zjistil chybu č. 2011 (Chyba ve struktuře ID DS) a tu vrátil. Ale kam se ztratila ta odpověď už nedokážu říct. V našich lgách není žádná abnormalita
Pravdou je, že v minulém a tomto týdnu je na TESTu větší provoz, protože některé velké spisovky testují. A Vy to zkoušíte v době největší špičky. A hlavně na TESTu je jediný aplikační server, zatímco na produkci jich je v balancingu mnohem víc.Produkční prostředí je mnohem více sledováno a monitorováno.
Mám za to, že na produkci, když ty dávky budete rozesílat večer, tak bude vše OK.
Jan Šíma