Kuidas teha SharePoint’i rakenduste silumine lihtsamaks
11.12.2007 | Gunnar
SharePoint'i arendustega tegeledes, millest eriti head ja huvitavad mälestused on mul töövoogudega seoses, tekib varem või hiljem küsimus, kas saaks rakenduste silumise kuidagi lihtsamaks muuta. Eriti olukorras, kus Visual Studio debugger otsustab mitte enam töötada ja pangestub sädemeid pildudes. Probleemile on olemas lihtne asendusmetoodika, mis minu praktikas on seni hästi töötanud.
Mina töötan tihti läbi erinevaid näited ning proovin tihti ka igasuguste uute ülesannete juures neid rakendada. Esineb palju olukordi, kus SharePoint'is tekib viga ning veateade on suhteliselt sisutu. Näiteks, mida arvata sellest, kui veasituatsiooni sattunud töövoog teatab, et Error occured? Minus tekitab selline veateade ärevaid ja segaseid tundeid, kuna see lõhnab selle järgi, et tuleb pikk ja põnev õhtu. Paljud teised aga võivad selliste teadete peale muutuda morniks ning minetada eluisu. Aga olgem rõõmsad, sest ma pakun teile välja ühe lihtsa nõksu, kuidas edukalt oma koodis esinevaid vigu püüda.
Minu esimene seisukoht on see, et kui me vea kinni püüame, siis saame juba ise otsustada, kus seda viga võiks näidata. Tehnilised veateated enamasti lõppkasutajat ei huvita ning pigem satuvad nad segadusse sellest. Meile, tehnikutele, aga on sellised veateated äärmiselt olulised, sest enamasti peitub seal vastus probleemse koha kohta.
Minu teine seisukoht on see, et töökood võib olla must ja räpane ja sisaldada erinevaid lollusi, kuid seda seniks kuniks oleme kõik käima jooksnud. Sealt edasi teeme koodi korda ja viskame üleliigse rämpsu ära. Alles siis ütleme, et ülesanne on täidetud. Lähemalt võib sellest lugeda käesoleva blogi kandest Kuidas see jupp koodi sai võtta nii palju aega?.
Aga asume asja juurde. Oletame, et arendame mõnda olulist web part'i ning seal tekivad arenduse käigus vead, mille kohta SharePoint meile olulist infot ei anna. Võime oletada ka seda, et arendame mõnda töövoogu ning püüame andmeid liikuma saada erinevate toimingute vahel töövoos. Situatsioon on sel juhul isegi keerulisem, sest kuhugi pole veateateid võimalik välja ka kirjutada.
Vaatame järgmist koodi, mille korral veateke on 100% kindel.
{
object o = null;
o.ToString();
}
Töövoo korral saame töövoo seisundiks Error ja sellega asi lõpeb. Järgmiseks püüan ma selle vea kinni ning pistan selle ei kuhugi mujale kui Event Log'i. Kood on selline.
{
try
{
object o = null;
o.ToString();
}
catch(Exception ex)
{
// EventLog asub nimeruumis System.Diagnostics
EventLog.WriteEntry("Application", ex.ToString());
}
}
Kui vaatad Event Log'i, siis näed, et sinna on tekkinud uus veateade, mis pole just kõige lakoonilisem. Kui soovid rohkem infot, siis vii SharePoint silumise režiimi ning anna oma rakendusega kaasa ka vastav program debug database (see on see rakenduse nimega fail, millel on pdb-laiend).
Siit edasi võiks kaaluda ka seda, et kirjutada eraldi projekt, milles on logimise klass. Miks mitte kasutada sellist softi nagu log4net. Logimise klassil võiks olla näiteks staatiline meetod Log(), mis kirjutab veateate vastavasse logisse, kuhu vaja.
Minul on see meetod hoidnud arenduste juures seni aega kokku päris metsikult, sest kõik vead tulevad välja kiiresti ja koos põhjaliku infoga.
12.12.2007 kell 19:43
Soovitan vigade korral uurida event logist ka seda, kas mõni SharePointiga seotud teenus pole veaolukorda sattunud.