Řešení problémů komunikace v síti EWP

link

Vytvoření výjezdové LA pro navazující studium

link

Můžu vytvořit výjezdovou LA pro BIP?

link

Příjezdová LA přišla přes síť EWP, ale vy ji takto spravovat nechcete

link

Příjezdová LA duplikuje příjezd

link

Příjezdová LA duplikuje osobu

link

Příjezdová LA neobsahuje změny

link

Datum začátku a konce mobility

link

Akademický rok u předmětu je v příjezdové LA špatně

link

Druhá strana změnila kooridnátora u podepsané LA

link

V příjezdové LA není možné napárovat předměty

link

Příjezdovou LA není možné podepsat

link

Podepsal jsem příjezdovou LA, ale nic se nestalo

link

Podepsal jsem příjezdovou LA dvakrát a druhý pokus skončil chybou

Poznámka pro administrátory:
Pokud
 dojde k opětovnému pokusu o podepsání již podepsané LA, cizí systém
vráti chybu. Tato chyba zůstane uložena v IS/STAG a zobrazuje se
uživatelům jako poslední provedená akce s LA. Pokud chcete, aby se
uživatelům správně zobrazovala hláška o úspěšně podepsané LA, můžete
přebytečné chybové zprávy odstranit z tabulky EWP_AKTUALIZACE. Avšak
jedná se pouze o kosmetickou úpravu, na fungování aplikace nemá tato
chybová hláška žádný vliv. 

link

Podepsal jsem příjezdovou LA a pak jsem objevil chybu

link

Po stažení dat zůstává příjezdová LA nepodepsaná

Pokud jste postupovali podle návodu Podepsal jsem příjezdovou LA, ale nic se nestalo, je nutné zjistit, kde nastal problém. Postupujte podle části Používání logu nebo kontaktujte administrátora.

Hledáme logy, které obsahují:

• podpis LA
  • cizí url, která v sobě pravděpodobně obsahuje řetězec "update"
  • data podpisu <omobility-las-update-request> s omobility-id (id příjezdové LA) a changes-proposal-id (id aktuální verze předmětů, které podepisujete)
  • identifikátory lze zobrazit v datech příjezdové LA (Zobrazit data z EWP)
• stažení dat LA
  • cizí url, která v sobě pravděpodobně obsahuje řetězec "get"
  • parametry requestu budou obsahovat sending_hei_id a omobility_id
  • identifikátory lze zobrazit v datech příjezdové LA (Zobrazit data z EWP)

Možné problémy:

• Pokus o podpis skončil chybou
  • og: obsahuje "update proposal" (podepsání LA/CHLA), na které druhá strana odpoví se statusem 409
  • tato chyba znamená, že se snažíte podepsat starší verzi LA nebo že jste LA již podepsali/vrátili s komentářem k přepracování
  • aktualizujte data této LA a pokud se vše stáhne správně, možnost podpisu Vám z LA zmizí a zobrazí se Vám aktuální data
• Pokus o stažení dat vrací stará data bez podpisu
  • log: obsahuje "update proposal" (podepsání LA/CHLA), na které druhá strana odpoví se statusem 200 a zprávou, že podpis byl úspěšně uložen
  • log: obsahuje pokus o stažení dat, ale XML data stále obsahují element <changes-proposal> se stejným id
  • LA/CHLA je tedy podepsaná, jen my si tuto informaci nedokážeme stáhnout
  • chyba je na straně druhé instituce, je nutné jim tuto chybu nahlásit
  • můžete jim přiložit log s úspěšným podepsáním a problémovým stažením jejich dat
• Pokus o stažení dat končí chybou
  • log: obsahuje "update proposal" (podepsání LA/CHLA), na které druhá strana odpoví se statusem 200 a zprávou, že podpis byl úspěšně uložen
  • log: obsahuje pokus o stažení dat, ale končí chybou, i když předchozí pokusy o stažení dat probíhaly v pořádku (se stejnými parametry sending_hei_id a omobility_id)
  • LA/CHLA je tedy podepsaná, jen my si tuto informaci nedokážeme stáhnout
  • chyba je na straně druhé instituce, je nutné jim tuto chybu nahlásit
  • můžete jim přiložit log s úspěšným podepsáním a problémovým stažením jejich dat

Pokud vrátíte nepodepsanou příjezdovou LA s komentářem, následná aktualizace dat Vám nestáhne žádné informace. Tato LA pro Vás bude nedostupná, dokud ji druhá strana neupraví a nepodepíše. Může se však také stát, že druhá strana LA úplně odstraní a už Vám ji poslat znovu neplánuje. V síti EWP není možné poznat rozdíl mezi dočasně a trvale nedostupnou LA. Pokud si nejste jisti, v jakém stavu se LA nachází, kontaktujte výjezdovou instituci mimo síť EWP a zeptejte se na stav příslušné LA. Na základě jejich odpovědi pak budete vědět, zda LA zachovat nebo zda ji můžete odstranit.

V budoucnu, až se v síti EWP budou používat nominace, bude možné zjistit, v jakém stavu je daná mobilita a zda náhodou nebyla zrušena. A na základě této informace pak můžete k dané LA přistupovat.

Pokud potřebujete podepsat LA v případě, kdy má fakultní koordinátor např. dovolenou, je možné, aby tuto akci za něj provedl institucionální koordinátor. Kdo LA ve skutečnosti podepsal se projeví v datech poslaných přes síť EWP a také je to zobrazeno přímo v aplikaci.

Známe chyby, které mohou nastat při správě LA přes síť EWP, jsou postupně doplňovány. Jak se orientovat v logu naleznete v části Používání logu.

Chyba po podpisu LA příjezdovou institucí

Pokud se příjezdová instituce snaží podepsat verzi LA, která již není k dispozici (byla upravena, podepsáná, vrácena s komentářem k přepracování), systém výjezdové instituce bude vracet chybový status 409. Příjezdová instituce si v tomto případě musí znovu stáhnout data výjezdové instituce a zachovat se podle těchto nových dat.

Digest mismatch on request!

Uri: ... cizí server ...
Request body:
<?xml ... ><omobility-las-update-request ... > ... <comment> Text komentáře &#13;
pokračování textu</comment><signature><ns2:signer-name>Anna Nováčková</ns2:signer-name> ... </omobility-las-update-request>

=============================================================================Polozka logu #2, cas: 30.11.2022 14:45:03:
Status: 400
Response body:
<?xml ... > ... <developer-message>Digest mismatch on request! calculated for body ... </developer-message></error-response>

Systém druhé instituce si nedokázal poradit s odřádkováním v komentáři LA. Znaky CR LF (&#13;&#10;) mohou v některých systémech způsobovat problémy při výpočtu ověření validity přijaté zprávy. Je nutné druhé instituci tento problém nahlásit, aby ho opravili. Rychlou opravou může být odebrání odřádkování z komentáře LA.

V tomto příkladu se nachází i druhý problém. Některé systémy mají problém s přijetím dat, která obsahují znak 'č'. Jelikož existují koordinátoři, kteří mají písmeno č ve svém jméně, nedokážeme to bohužel nijak nahradit a tento problém musí být nahlášen druhé instituci, aby ho opravili. Vzhledem ke specifikaci sítě EWP by tento znak neměl způsobovat žádné problémy.

Problémy s IIA

Sekce popisuje nejčastější problémy při přenosu dat Meziinstitucionálních smluv přes síť EWP.

Základní fungování:
Aktuálně to funguje tak, že Vy připravíte data, která budou dostupná v síti EWP pro protistranu. Následně, aby se o nich protistrana dozvěděla, pošlete notifikaci (CNR) tím, že kliknete na tlačítko "Potvrdit dokončení úprav". Druhá strana notifikaci přijme a následně si zavolá stažení dat podle uvedeného id. Dokud ale data nezpracuje a nepřipraví do stavu, který jsou ochotni schválit, žádná data Vám nevrátí. Výjimka byl Dashboard, který vracel data hned bez kontroly uživatele, ale to bylo špatně a už to upravili. Poté, co na druhé straně někdo data zkontroloval, převzal a případně upravil, Vám pošlou notifikaci s jejich id a systém sám automaticky data stáhne. Pokud tato smlouva obsahuje i Vaše id (což by měla), data se automaticky uloží do již existující smlouvy a Vám se zobrazí příznaky "Aktualizovat data přes EWP / Zobrazit data z EWP". Pak u Vás kooordinátor zkontroluje, zda druhá strana vrátila stejná data nebo provedla nějaké změny. Změny zapracuje nebo kontaktuje druhou stranu, že s něčím nesouhlasí, aby vše obě strany doladily. Poté můžete dát vědět oprávněné osobě, že může smlouvu schválit (v budoucnu to bude možné provést v aplikaci na tlačítko, které následně vytvoří portálové oznámení).

V případě, že smlouvu založí na druhé straně, bude proces probíhat opačně. Data převezmete a až je upravíte do podoby, se kterou souhlasíte, zveřejníte je druhé straně posláním notifikace (CNR) kliknutím na tlačítko "Potvrdit dokončení úprav". Dále vše postupuje stejně, jako v popisu výše.

Pokud se u smlouvy automaticky nenastaví možnost spravování přes síť EWP je potřeba ověřit následující situace:

Ověření připojení do sítě EWP

V EWP Stats portálu je možné podle erasmus kódu dané instituce ověřit, zda je připojená do sítě EWP. Pokud po zadání erasmus kódu nenaleznete žádný záznam, zkontrolujte nejprve, zda jste v erasmus kódu zadali správny počet mezer. Pokud je označení státu jednopísmenné, následují dvě mezery, po dvojpísmenném následuje jedna mezera a třípísmený kód nemá žádnou mezeru.

V případě, že instituce není vůbec připojená do sítě EWP, v části SCHAC code neuvidíte žádný údaj a položka "EWP details" bude šedivá (nepůjde na ní kliknout).

Pokud je instituce připojená, klikněte na položku "EWP details" a podívejte se, zda má uvedeného poskytovatele a verzi API v části "Interinstitutional Agreements". Pokud tam záznam nebude, instituce ještě není s tímto API připojená do sítě EWP a není možné s ní smlouvy přes tuto síť sdílet.

Ověření nastavení v IS/STAG

Pokud jste v předchozím kroku ověřili, že je druhá strana připojená do sítě EWP se smlouvami, je potřeba ověřit, zda je v IS/STAG správně nastaven její SCHAC code. Stává se, že instituce tento identifikátor potřebují změnit a občas při změně nedodrží předepsaný postup, a proto se v IS/STAG jeho hodnota automaticky nepřenastaví. V dané smlouvě se podívejte na položku "Partnerská škola" a klikněte na tlačítko "Změnit školu". V seznamu vyhledaných škol naleznete aktuálně zvolenou instituci. V položce SCHAC pak uvidíte uveden její identifikátor pro síť EWP. Porovnejte ho s identifikátorem, který jste nalezli v EWP Stats portálu v předchozím kroku. Pokud se neshodují, kontaktujete administrátora, ať tuto položku v IS/STAG opraví.

Poznámka pro administrátory:
Položka se nachází v číselníku škol ve sloupečku HEI_ID. Po přenastavení je nutné v portálu spustit aktualizaci konfigurace připojení, aby se opravilo nastavení připojení dané instituce a aktualizoval se příznak u smluv. Pravděpodobně je také vhodné spustit stažení všech Meziinstitucionálních smluv z tého instituce, protože se kvůli špatnému identifikátoru neuložily. Následně by koordinátoři měli smlouvy projít a sloučit (pokud se stáhly některé nové smlouvy, které by měly patřit k Vašim existujícím). Nakonec je pak možné ještě spustit stažení dat schválení smluv, které se také kvůli špatnému identifikátoru neuložily. 

Ověření nenašlo důvod problému

Pokud jste v předchozích krocích nenalezli důvod problému, nahlašte prosím tento problém Vašemu administrátorovi.

Ověřte připojení partnera a nastavení správného SCHAC kódu podle kroku Smlouvu není možné spravovat přes síť EWP.

Zkontrolujte log v portálu v záložce Administrace / Externí systémy / Logy a chyby. Log pro EWP je přístupný i koordinátorům.

• V položce Level můžete určit, zda chcete zobrazit bezproblémovou komunikaci (INFO), problémy v komunikaci (ERROR), nebo vše (%).
• Dále můžete nastavit časový interval, ve kterém se měla komunikace odehrát.
• Do položky Subjekt / kategorie uveďte SCHAC kód partnerské instituce.
• Do položky Kategorie 2 uveďte IIA.
• Do položky Podřetězec detailu uveďte cizí IIA ID (pokud Vám ho druhá strana poslala). Tím omezíte vyhledané záznamy pouze na ty, které se této konkrétní smlouvy týkají.

Pokud u záznamu směřuje šipka dolů, jedná se o komunikaci, kterou Vám druhá strana buď posílá notifikaci, že má připravená nová data ke stažení nebo si stahuje Vaše data. Pokud směřuje šipka nahoru, komunikace začíná na Vaší straně. Buď druhé straně posíláte notifikaci, že máte připravená nová data ke stažení nebo si stahujete cizí data.

Pokud naleznete záznam s označením ERROR, kontaktujte administrátora, ať se podívá, co nastalo za problém a zda je ho potřeba řešit na straně IS/STAG nebo na straně partnerova poskytovatele připojení do sítě EWP. Administrátor také může zadat stažení všech smluv dané instituce, které Vám tato instituce zveřejnila v síti EWP a případné chybějící smlouvy tím stáhnout.

Pokud po manuální aktualizaci všech smluv druhá instituce nevrací žádná data nebo vrací chybu, je nutné tuto instituci kontaktovat, že se Vám nedaří si jejich smlouvy stáhnout.

Pokud se stane, že založíte smlouvu paralelně s partnerem, budete mít dvě kopie stejné smlouvy, které budete potřebovat sloučit do jedné.

Sloučit je možné pouze neschválené smlouvy, kdy jedna z nich obsahuje pouze Vaše data a druhá obsahuje partnerova data. Pokud plánujete sloučit partnerovu smlouvu do Vaší, nepřebírejte data partnerovy smlouvy ani ji nezveřejňujte v síti EWP. Z této smlouvy se převezmou jen partnerova data a jinak se z ní vše smaže.

Zatím jsem neposlal mojí smlouvu partnerovi

Nejlepší situace na sloučení smluv je ta, kdy jste ještě Vaší verzi smlouvy partnerovi neposlali, ale máte již od partnera jeho verzi, která je uložená samostatně. V tomto případě je možné smlouvy bez problémů sloučit. V seznamu smluv zaškrtněte smlouvy, které chcete sloučit a klikněte na tlačítko "Sloučit".

V mojí smlouvě zatím nemám partnerova data

Pokud jste již Vaší smlouvu partnerovi poslali, ale ještě Vám ji nevrátil s jeho ID, můžete stále smlouvu sloučit s jeho smlouvou. V seznamu smluv zaškrtněte smlouvy, které chcete sloučit a klikněte na tlačítko "Sloučit".

Smlouva je již částečně schválená

Jakmile je smlouva částečně schválená, slučování již není možné. Pokud by však nastala situace, kdy se Vám partnerova data nenapárovali do Vaší smlouvy, ale jsou samostatně a partner Vaší smlouvu již schválil, kontaktujte administrátora a on Vám sloučení smluv provede.

Poznámka pro administrátory:
Pokud Vaše smlouva neobsahuje partnerova data, ale obsahuje jeho schválení a existuje smlouva, kterou by bylo možné s touto smlouvou sloučit, schválení smlouvy z databáze odeberte (MO_SMLOUVY.EWP_SCHVALENI_JSON). Jakmile smlouvy v aplikaci sloučíte, zavolejte v administraci stažení schválení smluv a schválení se do smlouvy zase nastaví zpět.

Obě smlouvy již obsahují partnerovo údaje

Pokud Vám již partner vrátil data k Vaší verzi slouvy a zároveň od něj máte samostatnou smlouvu, zkontrolujte, zda se opravdu jedná o jednu smlouvu, která je duplikovaná. Pokud ano, kontaktujte partnera a domluvte se, kterou z uvedených smluv odstraníte.

Zároveň není podstatné, kdo danou smlouvu vytvořil, pokud existují dvě smlouvy, které obsahují jak Vaše, tak partnerovo data, a z nich chcete zachovat pouze jednu, musíte kontaktovat partnera a domluvit se s ním, kterou z uvedených smluv odstraníte.

Aktuálně je na úrovni celé sítě EWP vymýšlen správný postup odstraňování neschválených smluv. Bohužel však bude ještě nějakou dobu trvat než bude plně dospecifikován a implementován.

Mám dvě vlastní smlouvy, které chci sloučit do jedné

Sloučení dvou vlastních smluv do jedné zatím v aplikaci IS/STAG není možné. Data musíte od jedné smlouvy k druhé přepsat ručně, jelikož u dvou vlastních smluv není možné určit, která data se mají z které smlouvy zachovat.

Jelikož data musí na druhé straně nejprve zkontrolovat a upravit tak, aby s nimi souhlasili, může nějakou dobu trvat, než se Vám smlouva z druhé instituce vrátí.

Pokud se chcete ujistit, že data jejich systém má, můžete se podívat do logu. Postupujte podle návodu v sekci Partner mě informoval o tom, že mi poslal smlouvu, ale já ji nevidím a ověřte, zda komunikace proběhla. Hledáte poslání CNR na druhou stranu a stažení Vašich dat. Pokud tam něco neproběhlo nebo skončilo chybou, kontaktujte prosím administrátora.

Případně se můžete partnera zeptat (e-mail, telefon), zda se mu Vaše smlouva v systému zobrazuje.

Pokud potřebujete určit, jakému koordinátorovi chcete smlouvu předat ke zpracování, v dolní části smlouvy se Vám zobrazují ISCED kódy z podmínek, které přišly přes síť EWP z partnerské instituce. Také můžete do smlouvy přidat pracoviště, která do ní zadal partner, pokud k podmínkám vyplnil Vaše nebo jejich pracoviště a podle toho to zkusit také odvodit.

Nebo Vám partner mohl sdělit ID jejich verze smlouvy, které se také zobrazuje v dolní části detailu smlouvy, a s tím Vám předat informaci, se kterou fakultou smlouvu uzavírá.

Všechny položky, které jsou označené indexem "EWP" je možné přenášet přes síť EWP. Tyto položky chcete od partnera převzít, pokud Vám je pošle a Vy s nimi souhlasíte. Přebíráte položky jak v detailu smlouvy, tak následně i pracoviště a podmínky smlouvy.

Na schvalovací proces mají vliv pouze změny v záložce Podmínky a podzáložce Přiřazená pracoviště. Ostatní převzatá data schvalovací proces neovlivní.

Data partnera se nezobrazí

Zkontrolujte, zda máte uložené partnerovo ID smouvy. Pokud ne, tak Vám ho buď ještě neposlal, a proto nebyla data stažena, nebo nastala chyba během komunikace. Postupujte podle části Používání logu. Pokud nastala chyba při uložení dat, zkuste data znovu stáhnout a pokud ani to nepomůže, kontaktujte administrátora, ať zhodnotí, zda je chyba na druhé instituci nebo zda nám má tuto chybu nahlásit k opravení.

Nemáme stažený seznam pracovišť

Ověření proveďte podle návodu v sekci Pracoviště smlouvy.

Nejprve ověřte, zda máte data protistrany. Pokud se Vám u smlouvy nezobrazují žádná data, která by přišla přes síť EWP, je možné, že partner Vám smlouvu ještě nevrátil zpět. Nebo je možné, že data protistrany přišla v samostatné smlouvě.Tato situace nastává, kdy z druhé strany přijde smlouva, která neobsahuje ID Vaší smlouvy. Může to být z toho důvodu, že tato smlouva přišla ještě před zveřejněním Vaší verze smlouvy nebo druhá strana zapomněla do jejich smlouvy ID Vaší smlouvy přidat. Tuto situaci vyřešíte podle návodu v části Mám duplikovanou smlouvu.

Pokud žádnou další smlouvu nenaleznete, můžete se podívat do logu, zda nedošlo k chybě v komunikaci. Postupujte podle návodu v sekci Partner mě informoval o tom, že mi poslal smlouvu, ale já ji nevidím.

Pokud data protistrany máte, smlouvu je možné schválit pouze v případě, že jste již provedli všechny úpravy a protistranu informovali o Vaší nové verzi dat kliknutím na tlačítko "Potvrdit dokončení úprav".

Aktuálně neprobíhá žádná automatická kontrola dat, která by Vám nedovolila smlouvu schválit kvůli rozdílnosti Vašich dat a dat partnera. Tuto kontrolu musíte provést sami.

Správný postup mazání smluv se aktuálně řeší na úrovni návrhu protokolu EWP. Podle posledních informací to ale vypadá, že podle podmínek Erasmu je možné smazat pouze smlouvy, které ještě nebyly schválené z obou stran. Jakmile je smlouva schválená z obou stran, je již platná a není možné ji smazat. Maximálně se školy mohou domluvit na jejím ukončení. Jak bude řešeno ukončení smlouvy v síti EWP zatím není dospecifikováno. Správný postup bude dořešen v průbehu letošního roku.

Dále není možné smazat smlouvu, která je uvedena v nabídce výjezdu. Buď ji musíte ze všech nabídek odebrat nebo vyměnit za jinou.

Pokud chcete smazat smlouvu, kterou sdílíte přes síť EWP, dejte to partnerovi věděť, ať ji ve svém systému také odstraní. V budoucnu by to již mělo být řešeno v rámci komunikace v síti EWP.

Pokud Vám partner tvrdí, že smlouvu schválil, ale vy to v systému nevidíte, mohla nastat jedna z uvedených situací.

Pozn.: Schválení smlouvy nesouvisí s datem podpisu smlouvy. Více informací se nachází v sekci Je/není vyplněn datum podpisu smlouvy.

Partner smlouvu schválil, ale Vy jste ji následně upravili

Pokud ve smlouvě po schválení upravíte její podmínky, je potřeba provést nové schválení ze strany partnera. V IS/STAG sice zůstane původní schválení uloženo, ale u smlouvy se zobrazuje, zda je schválena aktuální verze. Proto po Vaší úpravě uvidíte, že smlouva již ze strany partnera schválená není.

Partner schválil starší verzi smlouvy, kterou již v síti nezveřejňujeme

Pokud se například v důsledku chyby stane, že si partner nestáhne poslední verzi smlouvy, může nastat situace, kdy schvaluje některou z předchozích zveřejněných verzí. Pokud přes síť EWP přijde schválení aktuálně neexistující verze smlouvy, IS/STAG toto schválení neuloží. Zda nastala tato situace se dá zjistit v logu. Postupujte podle návodu v sekci Partner mě informoval o tom, že mi poslal smlouvu, ale já ji nevidím. Zkuste se podívat do logů a najít tam schválení Vaší verze smlouvy od partnera (podle Vašeho id smlouvy) a v něm se podívejte na hash, pro který byla smlouva schválena. Pak najděte poslední stažení Vašich dat partnerem a v nich najděte také hash. Pokud budou rozdílné, partner schválil starší verzi smlouvy, která již není platná. Pokud chcete zjistit rozdíl mezi schválenou verzí smlouvy a Vaší poslední verzí smlouvy, můžete v logu najít podle hashe ze schválení smlouvy i tuto verzi smlouvy. Následně můžete obě XML porovnat a podívat se, co se na Vaší straně změnilo a případně na to partnera upozornit.

Aby tato situace nenastávala, bude pravděpodobně zavedeno povinné stažení dat před provedeným schválením smlouvy, které budou systémy automaticky provádět a pokud naleznou novější data, uživatele při schválení upozorní, že se pokouší schválit starší verzi smlouvy a že nejprve musí převzít data a následně provést nové schválení.

Některé cizí systémy umožňují, aby partner již schválenou smlouvu upravil a následně tyto úpravy schválil. Bohužel existují i systémy (např. Dashboard), které aktuálně uživatelům nedovolují oboustranně schválenou smlouvu upravit a znovu schválit. Tato možnost bude v budoucnu povinná, ale dříve než v průběhu roku 2024 se tato povinnost nezavede. Aktuální řešení, které bylo s některými školami vymyšleno je smlouvu zkopírovat, upravit na správné hodnoty a schválit jako novou smlouvu. Zda původní smlouvu bude v druhém systému možné smazat nebo se bude muset počkat na možnost jejího ukončení (které se zavede také až v průběhu roku 2024) bude na druhé instituci, to na naší straně ovlivnit nedokážeme.

Zároveň doporučujeme před kliknutím na tlačítko "Schválit" důkladně zkontrolovat, zda jsou data přijatá z druhé instituce přes síť EWP a data uložená v IS/STAG opravdu stejná a souhlasíte s tím, co od partnera přišlo.

Nastala chyba v komunikaci přes síť EWP

Je možné, že nastala chyba při přenosu informace o schválení. To můžete ověřit v logu. Postupujte podle návodu v sekci Partner mě informoval o tom, že mi poslal smlouvu, ale já ji nevidím. Pokud naleznete záznamy označené jako ERROR, došlo k chybě a je nutné kontaktovat administátora.

Pokud po Vašem schválení dojde ke změně dat, je nutné tato nová data schválit. Projděte prosím podmínky smlouvy, převezměte partnerova data a následně smlouvu znovu schvalte.

Poznámka pro administrátory:
Co se přesně stalo se dá zjistit z logu. Lze porovnat hash ve stažených datech a hash ve schválení této smlovy. Pokud je hash v naposledy stažených datech jiná, než ta, kterou jste poslali ve schválení, byly změněny podmínky smlouvy a poslední verze smlouvy není schválená. Toto přesně dělá IS/STAG a pokud zjistí v těchto hodnotách hash rozdíl, zobrazí uživateli znovu možnost schválení. 

Datum podpisu smlouvy je položka, která není nijak závislá na schvalování smlouvy. Může se stát, že ji cizí systém vyplní ještě před schválením smlouvy, nebo ji naopak po schválení smlouvy vůbec nenastaví (u podpisu protistrany). IS/STAG náš datum podpisu smlouvy nastavuje automaticky podle prvního schválení této smlouvy. Pokud Vám přes síť EWP přijde datum podpisu smlouvy, můžete tuto položku ignorovat, dokud nebudete mít smlouvu schválenou. Naopak pokud toto datum ani po schválení nepřijde, můžete ho nastavit sami nebo informovat druhou stranu, ať ho do dat doplní.

Podle specifikace má datum podpisu smlouvy obsahovat první datum podepsání smlouvy (v IS/STAG uvádíme datum prvního schválení). Pokud se bude smlouva měnit a znovu schvalovat, toto datum se již nezmění.

Pokud Vám ve smlouvě přijdou pracoviště druhé instituce, ale Vám se k výběru nenabízí, mohla nastat jedna ze dvou situací.

Buď se při stažení pracovišť a jejich uložení něco nepovedlo. To lze ověřit v logu. Postupujte podle části Používání logu nebo kontaktujte administrátora. Komunikace ohledně dat pracovišť se v logu nachází pod kategorií OUNIT. Administrátor má možnost zavolat manuální aktualizaci  seznamu pracovišť dané instituce.

Nebo není druhá strana připojena s pracovišti do sítě EWP. To je možné ověřit v EWP Stats portálu. Postupujte podle bodu Smlouvu není možné spravovat přes síť EWP podle části Ověření připojení do sítě EWP, kde hledejte API v části General Purpose APIs, konkrétně Institutions a Organizational Units. V případě, že druhá strana není s těmi to API připojena do sítě EWP, neměla by Vám jejich pracoviště ve smlouvě posílat. Tuto informaci jim prosím nahlašte.

Zároveň podle specifikace EWP není nutné přebírat cizí pracoviště, takže i když druhá strana data a připojení neopraví, nic se neděje a smlouvu s nimi můžete uzavřít i bez jejich pracovišť.

BIP (Blended Intensive Programmes) se aktuálně přes síť EWP řešit nedá. BIP je uzavírán mezi třemi institucemi, v EWP jsou však aktuálně možné smlouvy pouze mezi dvěma.

Známe chyby, které mohou nastat při správě meziinstitucionálních smluv přes síť EWP, jsou postupně doplňovány. Jak se orientovat v logu naleznete v části Používání logu.

Pokud není vypočtená hash podmínek smlouvy stejná, jako hash uvedená v datech smlouvy, IS/STAG odmítne tato data uložit do databáze. Data z logu, která jsou zobrazena nad touto hláškou vložte do validátoru. Pokud validátor vrátí, že očekává jinou hash (a je stejná jako ta, kterou IS/STAG vypočítal), chyba je na straně druhé instituce. Tento problém prosím nahlašte na EWP Service Desk, který kontaktuje poskytovatelé daného systému, aby chybu opravil.

Aktuální známé problémy:

• Problém s odřádkováním v položce Další informace v podmínkách smlouvy. Znaky CR LF (&#xD;&#xA;) v podmínkách smlouvy způsobují problém s vypočtením hash ze strany Dashboard. Pokud nechcete čekat na opravu, odeberte odřádkování v datech podmínek smlouvy a požádejte partnera, aby tato data převzal a poslal Vám je zpět bez odřádkování.
• Hash je uložená v systému protistrany, i když se změnily podmínky. V jednom z předchozích logů naleznete jiné podmínky se stejnou hash.

Poznámka pro administrátory:
Může se stát, že data v logu budou mít rozbité kódování (ukládají se do databáze, která není v UTF-8). Pokud by byl místo nějakých znaků v datech otazník, je lepší si ten samý log najít na serveru v souboru ws-esb.log, kde najdete přijatá data bez jakýchkoliv úprav. Většinou se data ale uloží i do databáze v pohodě, takže do tohoto logu většinou chodit nemusíte.

HEI_ID se automaticky stahuje z katalogu sítě EWP. Bohužel pokud dojde ke změně, která neproběhne správným předepsaným postupem, tak ho automaticky nepřepisujeme. Správně by při změně měli původní hodnotu uložit do položky na to vyhrazené, ale vypadá to, že to nikdo nedělá. V akcích pro aktualizaci dat se vždy zobrazuje správně, protože tam je seznam vytažen z katalogu EWP (vůbec se nedívá do DB).

Pokud bude HEI ID špatně konktaktujte administrátora, aby ho v IS/STAG upravil.

Uri: ... cizí server ...
Request body:
hei_id=server.eu&iia_id=1234

=============================================================================Polozka logu ...
Status: 200
Response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><iias:iias-get-response ... </iias:iia></iias:iias-get-response>

=============================================================================Polozka logu ...
org.springframework.dao.DataIntegrityViolationException: PreparedStatementCallback; SQL ...
insert into mo_smlouvy
    ( ... )
values
    ( ... )]; ORA-01400: do ("INSTALL2"."MO_SMLOUVY"."CIZI_SKOLAIDNO") nelze vložit hodnotu NULL
...

V logu se tato chyba projeví výše uvedeným příkladem. Nebude možné uložit data smlouvy, protože systém nedokáže uvedené HEI ID nalézt v číselníku škol a podle něj najít interní identifikátor dané školy.

Poznámka pro administrátory:

Položka
 se nachází v číselníku škol (tabulka CIS_SKOL) ve sloupečku HEI_ID. Po jejím přepsání na nové aktuální HEI a případně i opravě názvu (přepsat přímo v DB) je nutné v portálu spustit aktualizaci konfigurace připojení (Administrace - Externí systémy - Akce a zde API "Aktualizuj konfiguraci připojení(po změně parametru připojení)"), aby se opravilo nastavení připojení dané instituce.
Pravděpodobně je také vhodné spustit stažení všech Meziinstitucionálních smluv z této instituce (API "Meziinstitucionální smlovy") pro toto konkrétní nové HEI, protože se kvůli špatnému identifikátoru nemusely všechny smlouvy uložit.
Následně by koordinátoři měli smlouvy projít a sloučit (pokud se nyní stáhly některé nové smlouvy, které ale kopírují Vaše již existující - jen pod novým ID).
Nakonec je pak vhodné ještě spustit i stažení dat schválení smluv (API "Schválené meziinstitucionální smluvy"), které se také kvůli špatnému identifikátoru nemusely původně uložit/dotáhnout.

Obecné problémy

Ověření prostředí

Pokud se jedná o testování, je možné, že se partner dívá do špatné sítě. Ujistěte se, že oba data zadáváte nad DEV síti EWP.

Ujistěte se, že máte dané API zveřejněné v síti EWP. Nastavení v testovací siti i v produkční síti je závislé na parametru EWP_ZVEREJNENA_API. Ujistěte se, že je parametr správně nastaven.

Pokud parametr nebyl nastaven, je pravděpodobné, že se jeho nastavení hned nevypropaguje do sítě EWP a bude nutné nějakou dobu počkat. Druhý den by vše již mělo být dostupné.

Ověřit připojení do produkční sítě EWP můžete také v EWP Stats portálu.

Popis fungování:
Do databáze se ukládají pomocné hodnoty, které také ovlivňují chování aplikace. Nestačí proto jen přenastavit parametr EWP_ZVEREJNENA_API, ale je také nutné, aby následně proběhla aktualizace dat. Aktuálně je přenastavení pomocných hodnot součástí aktualizace všech API (buď automatické noční, nebo i manuální).
V budoucnu toto oddělíme do samostatného procesu, aby bylo možné spustit nastavení pomocných hodnot i mimo velkou aktualizaci dat. Následně to bude možné navázat i na změnu hodnoty tohoto parametru, takže pak již nebude nutné nic dalšího řešit.
Zároveň ale asi stále bude platit to, že pokud API zveřejníte, druhá strana o tom nemusí vědět hned.

Ověření logu

Pokud jsou data ve správném systému a vše je nastaveno správně, je potřeba se podívat do logu, zda v uvedený čas proběhla mezi systémy komunikace. Budete hledat informace podle SCHAC kódu (HEI ID) a příslušného API (LA, IIA, ...). Hledáte logy, které v detailu obsahují v adrese části jako "cnr" (notifikování o datech) nebo "get" (stažení dat). V těchto logách můžete zjistit, zda systém druhé strany nevrátil chybu nebo zda chyba nenastala na straně IS/STAG při zpracování dat.

Podrobnější popis naleznete v části Používání logu.

Informace z druhé strany

Pokud v logu není v uvedenou dobu žádná komunikace, je potřeba získat více informací od druhé instituce. Nejlépe informace o requestu a response z jejich logu.

Stažení dat z protistrany

Přístup mají pouze administrátoři.

V záložce Administrace / Externí systémy / Akce jsou akce pouze pro stažení dat z protistrany, tj. není tam nic, co by naopak vyvolalo poslání dat protistraně. Je to rozdělené přes jednotlivá rozhraní EWP.

• Všechna API - Provede kompletní stažení dat ze všech institucí. Aktuálně by nemělo být potřeba, vždy je lepší volat stažení dat jen pro konkrétní instituci, kde si myslíme, že mohlo dojít k výpadku dat.
• Aktualizuj konfiguraci připojení (po změně parametru připojení) - Pokud bylo změněno připojení k síti EWP nebo SCHAC kód (HEI ID) některé instituce, je možné spustit aktualizaci konfigurace, která je uložená v databázi. Toto se automaticky pouští každou noc.
• Instituce - Stáhne informace o instituci. Může obsahovat i seznam identifikátorů pracovišť instituce. Pro každou instituci, se kterou evidujeme v systému meziinstitucionální smlouvu, se spouští jedenkrát za týden automaticky.
• Pracoviště - Pokud máme stažený seznam identifikátorů pracovišť v datech o instituci, provede aktualizaci informací o těchto pracovišť. Pro každou instituci, se kterou evidujeme v systému meziinstitucionální smlouvu,  se spouští jedenkrát za týden automaticky.
• Meziinstitucionální smlouvy - Zavolá stažení všech meziinstitucionálních smluv, které nám aktuálně druhá instituce sdílí přes síť EWP.
• Schválené meziinstitucionální smlouvy - Zavolá stažení všech schválení protistrany u smluv, které nám druhá instituce sdílí přes síť EWP (pokud ke smlouvě existuje).
• Factsheets - Zavolá stažení Factsheet pro danou instituci. Pro každou instituci, se kterou evidujeme v systému meziinstitucionální smlouvu,  se spouští jedenkrát za týden automaticky.
• Learning Agreements - Zavolá stažení všech příjezdových LA, které nám aktuálně druhá instituce sdílí přes síť EWP.

Většinou není potřeba toto volat, protože se data, která nemají CNR (notifikace o změně) stahují jedenkrát za týden automaticky. A ta data, která CNR mají, se stahují na základě takto přijatých CNR od protistrany. Nebo je možné konkrétní IIA a LA aktualizovat manuálně pro konkrétní data přímo v aplikaci ECTS výjezdy / ECTS příjezdy kliknutím na tlačítko "Aktualizovat data přes EWP".

Log

V logu najdete, zda v daný čas proběhla mezi systémy komunikace a jestli proběhla v pořádku nebo skončila chybou. Jeho část pro síť EWP je dostupná nejen administrátorům ale také koordinátorům.

Budete hledat informace podle SCHAC kódu (HEI ID) a příslušného API (LA, IIA, ...). Hledáte logy, které v detailu obsahují v adrese části jako "cnr" (notifikování o datech) nebo "get" (stažení dat). V těchto logách můžete zjistit, zda systém druhé strany nevrátil chybu nebo zda chyba nenastala na straně IS/STAG při zpracování dat.

• V položce Level můžete určit, zda chcete zobrazit bezproblémovou komunikaci (INFO), problémy v komunikaci (ERROR), nebo vše (%).
• Dále můžete nastavit časový interval, ve kterém se měla komunikace odehrát.
• Do položky Subjekt / kategorie uveďte SCHAC kód partnerské instituce.
• Do položky Kategorie 2 můžete uvést typ dat, který Vás zajímá (LA, IIA, FACTSHEET, INSTITUTION, OUNIT).

Základní výpis obsahuje:

• Směr komunikace (pouze pro EWP logy) - Komunikace mohla být vyvolána cizím systémem, který poslal CNR (notifikaci) o změnách v datech, poslal žádost o data nebo poslal podpis LA. Nebo ji mohl vyvolat IS/STAG, který provedl stejné akce do cizího systému.
• Aplikace - V rámci které aplikace byla událost uložena do logu.
• Level - Zda komunikace skončila úspěšně (INFO) nebo chybou (ERROR).
• Datum a čas - Kdy akce proběhla
• Subjekt - V případě EWP SCHAC kód (HEI ID) druhé instituce, se kterou komunikace probíhala.
• Kategorie - V případě EWP typ dat, kterých se akce týkala (LA, IIA, FACTSHEET, INSTITUTION, OUNIT).
• Text - Další informace o záznamu v logu.
• Detail - Podrobné informac o záznamu v logu (dotaz a odpověď, případně další informace).

Podrobnější popis položky Detail - dotaz z cizího systému:

Detailni informace o prubehu operace:
=============================================================================Polozka logu #1, cas: 15.02.2023 15:00:00:
REQ_IN
    Address: https://stag-demo.zcu.cz/ws/services/ewp/iias/get
    HttpMethod: POST
    Content-Type: application/x-www-form-urlencoded
    ExchangeId: ...
    Headers: ... 
    Payload: hei_id=zcu.cz&iia_id=1234


=============================================================================Polozka logu #2, cas: 15.02.2023 15:00:00:
RESP_OUT
    Address: https://stag-demo.zcu.cz/ws/services/ewp/iias/get
    Content-Type: application/xml
    ResponseCode: 200
    ExchangeId: ...
    Headers: ...
    Payload: <?xml ... ><iias-get-response ... <conditions-hash>123abc</conditions-hash></iia></iias-get-response>

• REQ_IN - Část dotazu do IS/STAG
  • Address - Jakého systému a na jaká data se cizí systém ptá.
  • Payload - Parametry dotazu (konkrétní identifikace dat, o která systém žádá nebo která notifikuje, že se změnila).
• RESP_OUT / FAULT_OUT - Část odpovědi z IS/STAG
  • ResponseCode - Informace pro cizí systém, jak dotaz skončil. Vysvětlení kódů se nachází v části Požadavek na server IS/STAG.
  • Payload - Data odpovědi.

Podrobnější popis položky Detail - dotaz z IS/STAG:

Detailni informace o prubehu operace:
=============================================================================Polozka logu #1, cas: 09.02.2023 15:00:00:
Uri: https://stag-demo.zcu.cz/ws/services/ewp/iias/cnr
Header Original-Date=[Thu, 09 Feb 2023 14:00:00 GMT]
...
Request body:
iia_id=5863&notifier_hei_id=zcu.cz

=============================================================================Polozka logu #2, cas: 09.02.2023 15:00:00:
Status: 200
...
Response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns7:iia-cnr-response ... />
=============================================================================Polozka logu #3, cas: 09.02.2023 15:00:01:
... Výpis chyby, která nastala při zpracování dat ...

• Část dotazu z IS/STAG
  • Uri - Do jakého systému a na co se IS/STAG ptá.
  • Request body - Parametry dotazu (konkrétní identifikace dat, o která IS/STAG žádá nebo která notifikuje, že se změnila).
• Část odpovědi z cizího systému
  • Status - Informace z cizího systému, jak u nich dotaz dopadl. Vysvětlení kódů se nachází v části Požadavek na server druhé instituce.
  • Response body - Data odpovědi.
• Chybová hláška
  • Výpis chybové hlášky - Např. nastala chyba při validaci dat a je zde zobrazeno, co bylo špatně a co bude potřeba nahlásit druhé instituci (proč se přijatá data neuložila).
  • Výpis chyby - Může obsahovat celou chybovou zprávu, kterou bychom chtěli v budoucnu nahradit pouze chybovou hláškou pro nahlášení druhému systému. Případně může obsahovat chybovou zprávu podle které určíme, zda a co je potřeba v IS/STAG opravit, aby komunikace probíhala správně.

Obecně je možné chyby rozdělit podle toho, která strana se na data ptala a která strana odpovídala. Následující shrnutí je obecná interpretache chybových kódů. Může se ale stát, že chyba je na jiné straně, než je uvedeno níže. Vždy je nutné projít XML odpovědi (poslední řádek dané položky logu) a další textové informace a podle nich zkontrolovat a vyhodnotit, kde chyba nastala.

Pokud se jedná o chybové kódy 4xx, chyba je pravděpodobně v systému druhé strany. Zároveň v odpovědi posíláme informaci, kde problém je a co by měli opravit. Podívejte se na další informace do XML odpovědi (poslední řádek této položky logu). 

• 400 - Zadané parametry requestu nebyly validní.
• 401 - Nastal problém při ověření klienta.
• 403 - Nastal problém při ověření klienta.
• 409 - Nastal konflikt při úpravě dat. Např. snaha podepsat starou verzi LA, která se již ale změnila.

Pokud se jedná o chybové kódy 5xx, chyba je pravděpodobně v našem systému. Zároveň v odpovědi posíláme, zda je chyba dočasná nebo zda ji budeme opravovat. Podívejte se na další informace do XML odpovědi (poslední řádek této položky logu) a případně nám nahlašte uvedený problém.

• 500 - Nastala chyba při zpracování dat, kterou budeme muset opravit.
• 503 - Server je dočasně nedostupný (pravděpodobně právě probíhala údržba).

Pokud se jedná o chybové kódy 4xx, chyba je pravděpodobně v našem systému. Zároveň v odpovědi nalezneme informaci, kde problém je a co bychom měli opravit. Podívejte se na další informace do XML odpovědi (poslední řádek této položky logu) a případně nám nahlašte uvedený problém.

• 400 - Zadané parametry requestu nebyly validní.
• 401 - Nastal problém při ověření klienta.
• 403 - Nastal problém při ověření klienta.
• 409 - Nastal konflikt při úpravě dat. Např. snaha podepsat starou verzi LA, která se již ale změnila.

Pokud se jedná o chybové kódy 5xx, chyba je pravděpodobně v systému druhé strany. Zároveň v odpovědi nalezneme informaci, zda je chyba dočasná nebo zda ji budou muset opravit. Podívejte se na další informace do XML odpovědi (poslední řádek této položky logu).

• 500 - Nastala chyba při zpracování dat, kterou budeme muset opravit.
• 503 - Server je dočasně nedostupný (pravděpodobně právě probíhala údržba).
• 200 - Požadavek proběhl v pořádku, data byla poslána. Při následné validaci v našem systému jsme buď zjistili, že data nejsou validní a nemůžeme je tedy uložit, nebo nastala při jejich ukládání chyba (buď přímo v aplikaci nebo v konfiguračních datech).

Konrétní příklady chybových záznamů

Pokud byl dotaz veden na náš server, odpověď (chybovou zprávu) vygeneroval IS/STAG a popisuje v ní, co nastalo.

401 - No authorization method found in the request

Detailni informace o prubehu operace:
=============================================================================Polozka logu ...
REQ_IN
 Address: ... náš server ...

=============================================================================Polozka logu ...
FAULT_OUT
ResponseCode: 401
Payload: ... <developer-message>No authorization method found in the request</developer-message> ...

Pokus o stažení dat ze serveru IS/STAG skončil chybou ověření, a proto IS/STAG vrátil chybový kód 401.

Podle uvedené zprávy v hlavičce requestu chybí HTTP Signature, což je aktuálně jediný možný způsob ověření v síti EWP. Chyba je na straně druhé instituce a je potřeba jim tuto informaci nahlásit.

400 - Signature not verified

Detailni informace o prubehu operace:
=============================================================================Polozka logu ...
REQ_IN
    Address: ... náš server ...
    Header Authorization=[ ... signature="SvM/RZscGBqmSiuT8FdPkvSmKF4vPyfbwQKYfs ... "]
    Payload: send_pdf=true&hei_id=server.cz&iia_id=1234

=============================================================================Polozka logu ...
FAULT_OUT
    ResponseCode: 400
    Payload: <?xml ... ><error-response ... ><developer-message>Signature not verified</developer-message></error-response>

Během ověření podpisu požadavku a jeho hlaviček bylo zjištěno, že uvedený podpis neodpovídá vypočtenému podpisu. Proto není možné druhému serveru poskytnout požadovaná data nebo jeho datům důvěřovat a uložit je. Na tuto situaci jsme narazili, když systém druhé instituce neuměl správně vypočítat podpis se speciálním portem serveru.

---

Pokud byl dotaz veden na cizí server, odpověď (chybovou zprávu) vynegeroval cizí server a popisuje v ní, co nastalo. Pokud se popis chyby nachází až v další položce logu za odpovědí, chybovou zprávu přidal IS/STAG.

400 - Institution not found

Uri: ... cizí server ...
Request body:
hei_id=server.eu

=============================================================================Polozka logu ...
Status: 400
Response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<error-response xmlns="https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd">
    <developer-message>Backend service returned: Institution not found</developer-message>
</error-response>

Server nenalezl instituci, která byla uvedena v parametru hei_id. Buď tato instituce na serveru opravdu neexistuje, nebo nastala na serveru chyba, kvůli které server vrátil tuto odpověď. Pokud jsme si jisti, že uvedené hei_id by měl server obsahovat, je potřeba tuto chybu nahlásit druhé instituci.

400 - ... the date does not match your server clock ...

Uri: ... cizí server ...
Request body:
hei_id=server.eu

=============================================================================Polozka logu ...
Status: 400
Response body:
<?xml ... ><error-response ...><developer-message>The date cannot be parsed or the date does not match your server clock within a certain threshold of timeDate.</developer-message></error-response>

Čas požadavku neodpovídá danému časovému intervalu, ve kterém může být tento požadavek zpracován na serveru. Jeden z těchto serverů má pravděpodobně špatně nastavený čas a je nutné ověřit, který z nich to je.

200 - Signature is not valid yet

Uri: ... cizí server ...
Header Original-Date=[Sun, 05 Mar 2023 05:20:38 GMT]
Request body:
hei_id=server.eu&ounit_id=ounit_id

=============================================================================Polozka logu ...
Status: 200
Header Date=[Sun, 05 Mar 2023 05:21:47 GMT]
Header Signature=[... created=1677993707 ...]
Header transfer-encoding=[chunked]
Response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns57:ounits-response ... data ... </ns57:ounit></ns57:ounits-response>

=============================================================================Polozka logu ...
org.tomitribe.auth.signatures.InvalidCreatedFieldException: Signature is not valid yet

Server v odpovědi uvedl hlavičku created, která obsahuje datum a čas vytvoření podpisu zprávy. Bohužel je tento čas v budoucnu a nevejde se do časového intervalu. Je nutné tento problém nahlásit druhé insitutuci, protože špatně podepsala odpověď s daty. Jelikož není podpis validní, nemůžeme tato data použít.

404 - HTML odpověď

Uri: ... cizí server ...
Request body:
sending_hei_id=server.cz&omobility_id=12345

=============================================================================Polozka logu ...
Status: 404
Response body:
...
<html>
...
<body style="height:100%"">
...
	<div class="page-wrap d-flex flex-row align-items-center">
	    ...
	    </div>
	</div>
</body>
</html>

=============================================================================Polozka logu ...
javax.ws.rs.client.ResponseProcessingException: No message body reader has been found for...
        ...

Server vrátil data, která nejsou v EWP formátu, a proto jeho odpověď nedokázal IS/STAG zpracovat. Zde cizí systém vrátil HTML stránku s kódem 404. Pravděpodobně vůbec nenašel adresu, na kterou se IS/STAG pokoušel připojit. Chyba je na straně cizího systému a mohlo dojít k ojedinělému výpadku. Pokud chyba přetrvává, je potřeba jim tento problém nahlásit.

Chyby v logu rozdělené podle aplikací

• Chyby v logu pro LA
• Chyby v logu pro IIA