Bližší kategorizace a obsluha chyb

V průběhu procesu zpracování požadavku na službu mohou vzniknout tyto kategorie chyb:

A. Obsluha chyby při nulté transformaci

Pokud nultá transformace selže bude na vstupní XML SOAP aplikována šablona:

Výsledkem této transformace je soap-fault pro odeslání v odpovědi na požadavek. Před použitím této šablony je nastavován její kmenový parametr Code na hodnotu Sender (bez prefixu), parametr Detail je pak naplňován obsahem hlášky SAXu, zdůvodňujícím selhání a také parametr Reason, který říká “Neplatný obsah pro vstupní transformaci.” (vraceno univerzálně v angličtině, tj “Invalid content for input transformation.”).

Případné selhání i této transformace je dáno neplatným XML. V takovém případě do odpovědi server pošle obsah souboru:

Pokud dojde k výskytu status=”error” v kmenovém uzlu ve výsledku transformace, bude použita stejnojmenná šablona soap-error.xsl, která je umístěna nikoli ve složce buildu, ale ve společné složce _transforms (protože ve složce buildu je error šablona jen při možnosti statusového erroru). Bude aplikována na výstup z nulté transformace s nastavením kmenového parametru Code šablony na hodnotu Sender (bez prefixu). Výsledek je odeslán jako odpověď.

Pokud bude po nulté transformaci zjištěno, že výsledkem je prázdný kmenový node, bude na tento výstup opět aplikována šablona soap-error.xsl ze složky buildu a opět s kódem Sender (bez prefixu), který odlišuje fázi průběhu. Výsledek je odeslán jako odpověď.

B. Obsluha chyby při transformaci dle substepu

Pokud vznikne chyba při transformaci dle nastavení substepu, tj. transformace selže, bude postup obdobný jako u transformace nulté, jen s tím rozdílem, že parametr Code budeme nastavovat na hodnotu Receiver (bez prefixu) a Reason na hodnotu "Invalid transform for handling the service."

Máme sice celkem jistotu ve validním vstupním XML, přesto bych nechal jako krajní možnost opět použití univerzálního souboru:

Obsluha výskytu status=”error” v kmenovém uzlu výstupu bude téměř totožná s nultou transformací a bude použita šablona ze složky buildu. Tou odlišností bude nastavení parametru Code na hodnotu Receiver (bez prefixu). Totéž platí pro situaci, kdy výstup z transformace je prázdný.

Finálního kroku se samozřejmě týká pouze obsluha selhání transformace.

C. Obsluha jakékoli další chyby způsobené chodem procesu či serveru

Pro obsluhu jakékoli jiné chyby je buď možností použít přímo soubor:

případně tento soubor vzít jako podklad pro transformaci pomocí šablony:

Kdy výsledkem této transformace bude opět soap-fault pro odeslání v odpovědi, ale s tím, že je možné (nikoli nutné) nastavit kmenové parametry Code (nejspíš na hodnotu Sender bez prefixu), parametr Detail a parametr Reason dle povahy chyby. Nebudou-li parametry nastaveny, bude obsahem výstupu téměř totéž, co je na vstupu, tedy soap-unifault.xml.

D. Obecná kontrola chyb v odpovědích na požadavky

Pokud je požadováno, aby výsledek transformace byl odesílán na server pomocí send="true", je po výstupu automaticky prováděn primární nativní test serverem na výskyt chyby v kdekoli v odpovědi. Tj. pokud bylo na server odesíláno více požadavků a v odpovědi min. na jeden z nich se vyskytne chyba, server vezme tuto odpověď a aplikuje na ni šablonu:

Odpovědí této dodatečné transformace pak je univerzálnější forma hlášení chyby. Pokud by bylo třeba provádět přesnější identifikaci chyb, je možné tuto nativní kontrolu po získání odpovědi vypnout nastavením atributu:

a nastavit následnou kontrolu dalším substepem, kdy vstupem do jím definované transformace bude výstup ze serveru a specifická šablona, která bude chyby zjišťovat přesněji.

Komunikační protokol serveru flexideo obsahuje nastavení pro identifikaci chyb jednotlivých požadavků. Tento protokol je používán webovým rozhraním pro nastavování transformací a nastavení pro identifikaci chyb použitých požadavků jsou přenášena do spec. šablony generované do složky buildu. Ta je pak aplikována na výstup ze serveru pomocí spec. substepu a zajišťuje základní aplikační test s ohledem na obecnou platnost každého použitého požadavku odesílaného na server. Tím je zajištěno, že každý požadavek se dle své povahy se účinně ověřuje. Významový aplikační test však automaticky prováděn není, pokud není nastavena odpovídající kontrola dat v pomocí uzlů result-check v souboru setting.mxl každé transformační akce. Pokud je tato základní aplikační kontrola rozšířena o významovou pomocí aplikační kontroly nastavované uzlem result-check, je kontrolní šablona rozšířena o patřičné součásti pro realizaci kontroly.