Identifikace chyb při ukládání XML dokumentů

Na rozdíl od získávání dokumentů je při jejich ukládání k dispozici hned několik forem hlášení chyby. První z nich je chyba vzniklá při základním ověřování ukládaných typů, tedy prvků ukládaných do sloupců tabulek databáze, kde každý z nich má předem daný určitý typ a velikost (viz. Část A - Definování intranetu). Nevyhovuje-li některý z ukládaných prvků označených atributem changed="true", vede to k chybě při uložení celého dokumentu a vrácení transakce. To znamená, že i již uložené prvky a případně i jiné dokumenty, je-li jich v požadavku více, se vrátí do původního stavu (transaction rollback). Při vzniku chyby při základním ověřování server vrátí v response obálce například takovouto identifikaci:

<save-result type="error" doc-type="kontakt" dkey="1234" orig-dkey="1234" detail="Pri provadeni zmen doslo k chybe.">
<error number="1002105" severity="warning" 
detail="Hodnota prvku neodpovida datovemu typu.(10001024)"/>
</save-result>

Atribut type tagu save-result obsahuje hodnotu error indikující chybu - toto je základní identifikace, zda byl dokument uložen či nikoli - a atribut detail s obecným popisem chyby.

Atribut detail tagu error obsahuje vedle detailnější informace o druhu problému také osmimístné číslo v závorce. Toto číslo je ID prvku dle XDS (a potažmo také DAD), kde se chyba obsahu nachází.

Je-li v požadavku na uložení save-document více potomků než jeden, například jeden dokument správně a druhý obsahuje výše zmíněnou chybu, pak nedojde k uložení ani jednoho dokumentu a server odpoví následující odpovědí v obálce respnse:

<save-result type="error" doc-type="kontakt" dkey="1234" orig-dkey="1234" detail="Pri provadeni zmen doslo k chybe.">
<error number="1002105" severity="warning" 
detail="Hodnota prvku neodpovida datovemu typu.(10001024)"/>
</save-result>
<save-result type="error" doc-type="kontakt" dkey="1235" orig-dkey="1234" detail="Neprovaden z duvodu vraceni transakce."/>

Je dobré si všimnout, že dokument, který chybu způsobil jako jediný obsahuje potomek error, zatímco dokumenty ostatní obsahují jen informaci o vrácení transakce. Ukládáte-li tak více dokumentů, je možné snadno vybrat ten, který chybu způsobil a vrátit tak podstatnou chybovou informaci.

Je-li požadavek na uložení více dokumentů rozdělen v rámci obálky request na více samostatných potomků save-document, pak dojde k uložení těch dokumentů, jež v rámci jednoho save-document neobsahoval chybu žádný z nich. Budeme-li tedy předpokládat, že do obálky request vložíme dva potomky save-document, kde každý z nich bude mít po jednom uzlu s dokumentem a dále budeme předpokládat, že jeden z těchto dokumentů obsahuje zmíněnou chybu, pak výsledný response bude mít tento obsah:

<save-result type="error" doc-type="kontakt" dkey="1234" orig-dkey="1234" detail="Pri provadeni zmen doslo k chybe."> 
<error number="1002105" severity="warning"  
detail="Hodnota prvku neodpovida datovemu typu.(10001024)"/> 
</save-result> 
<save-result type="ok" doc-type="kontakt" dkey="1235" orig-dkey="1234" />

Zde je jasně patrné, že druhý dokument se uložil, zatímco první nikoli.

Vedle chyby, která je odhalena aplikačním serverem flexideo může ale dojít k chybě vyvolané až SQL serverem. Například pokud v datu 20.11.2011 (pozn: v požadavku je ale nutný formát výhradně YYYY-MM-DD) prohodíme omylem měsíc se dnem, aplikační server tento druh chyby netestuje a problém nastane až při samotném pokusu o uložení do databáze. Pak v response najdeme přibližně takovýto obsah:

<save-result type="error" doc-type="kontakt" dkey="66009" orig-dkey="1234" detail="Pri ukladani doslo k chybe.">
<error number="1000080" severity="warning" 
detail="V provadenem databazovem dotazu doslo k chybe.(NATIVE='0' STATE='22007' 
DESCR='[Microsoft][ODBC SQL Server Driver]Invalid date format' ADDMSG='{? = call 
ps_plsml(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,)}')"/>
</save-result>

Pokud se snažíte změnit prvek, ke kterému nemáte přístup nebo políčko, které jednoduše neexistuje (např. uvedete nesprávný název tagu), pak server tuto chybu ignoruje, uložení daného prvku neprovede, ale zbytek dokumentu uloží bez identifikace chyby.

Ačkoli server neprovádí ukládání dokumentů v pořadí v jakém byly v požadavku, v odpověď na požadavek je vždy dodrženo pořadí z požadavku.

---

Identifikace chyb při ukládání XML dokumentůIdentifikace chyb při ukládání XML dokumentůPříklad požadavků na pseudo-dokumentyUkládání pseudo dokumentůEvidence historie změn dokumentůPříklad pro rozpracované dokuementyPřímé SQL dotazy do databázePříklady práce se souboryPříklad XML nastaveníPříklad seznamu naplánovaných úlohPříklad naplánování úlohyPříklad odložení požadavku do-requestPožadavek registerPožadavek register-listPožadavek register-delPříklad transformPříklad spuštění akcePříklad spouštění akcí pomocí zpráv

---