ÁghyBlog

Érdekes elemzés Gates és Jobs nemrégiben elhangzott Keynote-járól:

“Gates’ sentences were shorter this year than last. However, as in the past, Jobs fared better than Gates did in the various linguistic measures.“

Valójában angol háziként kaptam ezek elemzését, illetve az elemzés elemzését. Mindenesetre szakmai szemmel nézve még érdekesebb a dolog, nyelvi szempontból majd később nézek rá

A Search Core Results Web Part segítségével lehetőségünk nyílik arra, hogy saját oldalunkba ágyazva keresési eredményeket jelenítsünk meg. A keresés alapvetően kétféle módon történhet:

• UserQuery: a felhasználói lekérdezéshez szükségünk lesz egy Search Box vagy Advanced Search box webpartra, hiszen ezek segítségével történhet a keresési kifejezések bevitele. A kifejezés megadása után mindkét kontroll a QueryStringben helyezi el a megadott kifejezést, s az alapján jelennek meg az eredmények a Search Core Result kijelzőben.

Például: http://mymoss/sites/customsearch/default.aspx?k=42

• FixedQuery: Ha az a célunk, hogy egy fix kifejezésre vonatkozó találatokat jelenítsünk meg, felhasználói interakció nélkül, akkor erre a célra szolgál a kijelző FixedQery módja. Például így van lehetőségünk az adott scope összes prezentációját (ppt vagy pptx kiterjesztés) kilistázni.

Sajnos azonban a FixedQuery dinamikus felépítésére (programozás nélkül) nincs lehetőségünk. Ha például a mai napra szeretnénk lekérdezni (kinek van ma a születésnapja?), az akutális felhasználóra (mely dokumentumok vannak nála check-outolva) - erre nincs lehetőségünk. Hasonló a helyzet, ha bármi más tartalom alapján szeretnénk dinamikusan felépíteni a lekérdezést.

Dinamikus lekérdezés

Példánkban az URL alapján fogjuk indítani a lekérdezést. Egy másik site collection adott típusú (content type) elemei között kel azokat megkeresni, amelyekben a jelenlegi site URL-je szerepel.

A content type és a keresési scope létrehozására, valamint a scope és a Search Core Results kijelző összerendelésére most nem térnék ki, koncentráljunk az aktuális URL olvasására, és a keresőfeltétel dinamikus átadására.

Hozzunk tehát létre egy Search Core Results webkijelzőt, ám azt NE állítsuk át Fixed Query üzemmódba! Itt jön a meglepetés: a UserQuery módot fogjuk használni, beviteli mező nélkül. Ha az URL-t megfelelően paraméterezzük (ld. fent), a találati eredmények megjelennek a listában (42). Rendben, de hogyan adhatjuk meg automatikusan, beviteli mező nélkül ezt a “k” paramétert, ha azt szeretnénk, hogy az dinamikusan épüljön fel, ám az oldal valamennyi betöltésénél ki legyen töltve?

Az ember első gondolata az lehet, hogy az oldalra mutató linkekbe tegyük bele ezt a paramétert. Az ötlet majdnem jó, mindössze két probléma van vele:

• A befelé mutató URL-ben nem feltétlenül szép, ha telepakoljuk olyan paraméterekkel, melyek egyébként automatikusan számíthatóak. Nyilván vannak kivételek, egy ilyen URL-ben nagy valószínűséggel már senkit nem érdekel, hogy duplikálva van-e a GUID a végén: http://mymoss/sites/site_07dc3977-bb4c-4a82-9381-0726bd7e561a/Default.aspx?k=07dc3977-bb4c-4a82-9381-0726bd7e561a

• Saját hivatkozásainkba betehetjük ugyan a paramétereket, ám a SharePoint belül egészen biztosan nem fogja. Ha például az adott site-on lévő breadcrumb navigációt használva szeretnénk visszajutni a site nyitóoldalára, egészen biztosan nem fűzi az URL végére a saját paramétereinket…

Mi tehát a megoldás? Valahogyan az adott oldalba kell beletenni a paramétergenerálást, természetesen user input nélkül. A legoptimálisabb pedig az lenne, ha magába a Search Core Results kijelzőbe építhetnénk a paramétergenerálást, hiszen funkcionálisan ide tartozik.

A megoldás: a Search Core Result webpart mögötti XSL-t kell szerkeszteni a megfelelő helyen. Ebben az XSL-ben találjuk a megjelenítés paramétereit, illetve többek között azt is, hogy mit rendereljen a felhasználó számára, ha nincs találat (”No results matching your search were found.“), vagy ha hiányzik (üres) a paraméter. Ezt kell kihasználnunk!

Keressük meg tehát az alábbi kódrészletet az XSL-ben:

<xsl:template name=”dvt_1.noKeyword”>

<span class=”srch-description”>

<xsl:choose>

<xsl:when test=”$IsFixedQuery”>

Please set the ‘Fixed Query’ property for the webpart.

</xsl:when>

<xsl:otherwise>

Enter one or more words to search for in the search box.

</xsl:otherwise>

</xsl:choose>

</span>

</xsl:template>

Ez a rész felel annak kezeléséért, hogy mi történjen üres paraméter esetén. Az első ág az üres FixedQuery-t kezeli le - korábban már említettem, hogy a FixedQuery nem megoldás számunkra, úgyhogy nézzük a másik ágat. Ha (még) nincs kitöltve a keresőkifejezés, vagyis nincs “k” paraméter a QueryString-ben, az alábbi ág kerül végrehajtásra:

<xsl:otherwise>

Enter one or more words to search for in the search box.

</xsl:otherwise>

Vajon hogyan vehetjük rá a kijelzőt, hogy az üzenet megjelenítése helyett töltse ki saját magának a paraméter megfelelő, dinamikusan összerakott értékét? Javascript! Scriptből rajkuk össze a keresendő kifejezést, építsük fel a teljes URL-t a megfelelő QueryStringgel, majd az aktuális oldalt irányítsuk át ide. S az átirányítás utáni betöltésnél már egészen biztosan másik ágra fut a megjelenítés, hiszen már van “k” paraméterünk…

<xsl:otherwise>

<script type=”text/javascript”>

var kparam = location.pathname.substring(location.pathname.indexOf(”site_”), location.pathname.indexOf(”/Default.aspx”));

window.navigate(location.pathname + “?k=” + kparam);

</script>

</xsl:otherwise>

Természetesen ehhez hasonlóan a Javascript bármilyen algoritmus, bármilyen más adat alapján felépítheti a keresőkifejezést, nem muszáj az adott URL-ből dolgozni. Így lehet például megjeleníteni az aktuális napon születésnapot ünneplő felhasználók profile adatait, vagy az aktuális felhasználóhoz kivett (check out) tartalmakat is…

Ma ilyen elmélkedős kedvem van.

Miért van az, hogy a határidők vonzzák egymást? Vajon Murphy áll a dolgok mögött? Vagy a gravitáció?

Zsolttal beszélgettem a napokban, s bár teljesen máshonnan indult, és másfelé tartott ez a beszélgetés, mégiscsak egy érdekes kérdés motoszkál azóta a fejemben. Mi visz előre bennünket, informatikusokat? Megoldunk egy csomó problémát - majd azt vesszük észre, hogy ma már azok jelentik a megoldandó problémákat, amik tegnap még megoldásnak tűntek.

Ott vannak pl. az Rss olvasók. Néhány éve még nem volt google, nem volt Rss, az ember listájában volt néhány weboldal, amelyeket látogatott, ahol választ remélt kérdéseire, vagy ahol érdekes cikkekre számíthatott. Aztán elterjedtek a különféle keresők, s bármit is szeretnénk megtudni, pillanatokon belül elérjük. Sőt, Rss olvasással még azt sem kell tudnunk, mit akarunk tudni, hiszen a reader “tolja” ránk a feedeket. Ha feliratkozom egy Rss-re, lehet elképzelésem arról, milyen tartalmakat kapok majd, ám pontosan soha nem fogom tudni.

Az én Rss listám folyamatosan változik. Ha találok egy érdekes(nek) tűnő blogot, weboldalt, feliratkozom. Ha azt veszem észre, hogy néhány hete egyetlen bejegyzés sem tűnt olvasásra érdemesnek, akkor törlöm a listámból az adott feedet.

Még így is problémát jelent azonban, hogy hogyan dolgozzam fel a rám zúduló információmennyiséget. Régebben, lelkes ifjú titán koromban rengeteg feed volt a listámban, igyekeztem minden területen naprakészen tájékozott lenni. Ma már csak egy szűk terület, illetve néhány ismerős blogja szerepel itt, mégis százas nagyságrendben érkeznek naponta azon cikkek, melyek érdekesek, szakmailag fontosak, vagyis amelyeket el kell olvasnom.

Arról nem is beszélve, hogy hasonló ütemben nő az a lista, ahol a leblogolandó információkat (és cikkeket) gyűjtöm. Ezek nagy része persze elveszíti hírértékét, ha nem reagálja le az ember azonnal, így ez a lista is dinamikusan változik. A saját cikkekben pedig csak bízni tudok, hogy előbb-utóbb sorra kerülnek, s kiírhatom őket magamból.

Itt tartunk most: megoldódott az információk keresésének, elérésének problémája, ám ehelyett olyan mennyiségben és ütemben zúdul ránk minden, hogy ma már erre keressük a megoldást.

S holnap? Holnap mi lesz vajon?

Némi kihagyás után szerdán újra volt alkalmam részt venni az Architektúra Fórumon. István gyakorlatilag azonnal az esemény után részletes beszámolót írt, s már a fórumok is megnyíltak a kapcsolódó kérdéseknek.

Saját véleményem többé-kevésbé egyezik az Istvánéval, azzal a különbséggel, hogy én a Somogyi Csaba előadásán is maradtam. Ugyan nem vagyok rendszermérnök vagy -üzemeltető, mégis érdekes volt látni azt a víziót, amely a jövő virtualizációs lehetőségeit mutatja be. Kíváncsian várom, hogy Csaba “becslésének” megfelelően mikorra válik mindez valósággá, s milyen lépéseken keresztül jutunk el odáig. Első mérföldkő természetesen a Windows Server 2008 megjelenése, vigyázó szemetek tehát rá vessétek!

Három ingyenes MSPress könyv tölthető le erről a címről, regisztráció után:

• Introducing Microsoft LINQ
  by Paolo Pialorsi and Marco Russo
• Introducing Microsoft ASP.NET AJAX
  by Dino Esposito
• Introducing Microsoft Silverlight 1.0
  by Laurence Moroney

 Projektátadás… Ha az ember viszonylag jól tud 4-5 ujjal gépelni, akkor a két keze már két laptop kezelésére is elég, nem?

SharePoint listák alapján készítünk KPI-ket, az egyszerűség kedvéért tegyük fel, hogy number típusú oszlopot átlagolunk. A KPI létrehozásakor megadom a megfelelő lista URL-jét, és kiválasztom a nézetet, hogy mely nézet elemeit vegye figyelembe az átlag számításakor:

Amikor az átlagolandó oszlopot kell kiválasztani, érdekes dolgot tapasztaltam. A legördülő menüben nem a fent megadott nézetben megjelenő oszlopok jelennek meg, hanem az AllItems.aspx oszlopai! Vagyis a statisztikai oszlopokat (melyeket másra nem használunk, s egyenként a usereket sem érdekli), csak úgy tudok betenni KPI-be, ha kint van a lista AllItems.aspx-én.

De ez még semmi…

Kiteszem a megfelelő oszlopokat az AllItems-re, létrehozom a KPI-t, majd az AllItems-ről leveszem az oszlopokat (persze a megfelelő nézeten otthagyom). A KPI-k így is működőképesek maradnak! Sőt… a meglévő KPI-k EditForm-ját a megfelelő nézethez tartozó oszlopok szerepelnek, függetlenül az AllItems.aspx oszlopaitól. A NewForm azonban marad a fenti, vagyis ott az AllItems oszlopait látjuk mindig…

EditForm.aspx:   

NewForm.aspx:   

A workaround tehát a fenti módszer: ideiglenesen ki kell tenni a szükséges oszlopokat az AllItems (default) nézetre, majd létrehozni a megfelelő KPI-ket, s utána akár le is vehetjük az AllItems.aspx-ről a felesleges oszlopokat.

SharePoint 2007 alatt többféle lehetőségünk is nyílik a tartalmak mentésére és visszaállítására.

A központi adminisztrációs felületen manuális backupolásra van lehetőségünk: a teljes farmot, vagy azon belül egy-egy web application, site collection vagy SSP mentésére van lehetőségünk, de finomabb beállítási lehetőségekkel itt nem rendelkezünk.

A parancsssori megoldás már nagyobb szabadságot enged meg, ráadásul az utasítások script-szerű, időzített végrehajtásával már nemcsak manuális mentéseket készíthetünk, hanem valóban automatizálttá, sőt ütemezetté tehető a feladat végrehajtása.

A parancssorból tehát az stsadm utasítást kell hívni a megfelelő paraméterezéssel. Íme két nagyon egyszerű példa:

• Farm backup: stsadm -o backup -directory \\server\backupdir -backupmethod <full/differential>

• Site collection backup: stsadm -o backup -url <URL name> -filename <file name> [-overwrite]

Végül a harmadik, kevésbé ismert megoldással site-ok mentését és visszaállítását végezhetjük. Ez az eszköz pedig nem más, mint a SharePoint Designer! Ha megnyitunk egy site-ot, a menüben lévő Site menüpont alatt találunk egy Administration / Backup Web Site parancsot. Ennek segítségével .cmp (Content Management Package) formátumba menthetjük le site-unk tartalmát (az alsite-okkal együtt vagy azok nélkül).

A visszaállítás ebben az esetben némi trükközést igényel. Létre kell ugyanis hozni a megfelelő site-ot az új helyen, Blank site template alapján! Majd ezután erre a site-ra tudjuk visszaállítani az elmentett tartalmakat - gyakorlatilag egyetlen mozdulattal. Persze néhány dologra azért nem árt odafigyelni, például a telepített feature-ök meglétére és verziójára…

Először is mindenkinek nagyon boldog új évet kívánok!

Írtam egy nagyon klassz bejegyzést arról, hogy nem vagyok az a típus, aki ilyenkor mindenféléket megfogad, majd a következő 364 napban azon dolgozik, hogy ebből minél kevesebb teljesüljön… Szerintem az elhatározásoknak nem szabad attól függniük, hogy épp milyen napot írunk. Persze néha meg kell állni, én ebben látom az egész lényegét.

Arról is írtam, hogy most épp ez a pihenő véletlenül számomra is egybeesett a naptári mérlegelős időszakkal, 2007-et tehát úgy zárhattam, hogy pihentem és gondolkoztam. Sokat. -

Ez az írásom azonban egy FF fagysnak köszönhetően az enyészeté lett, alvitte a róka. Igazából azonban az évzáró-évnyitó merengéseim alatt semmi “meghatározóra” nem jutottam, úgyhogy nem fogtok itt “világmegváltó” dolgokat találni, akkor sem látnátok, ha meglenne az eredeti postom.

Remélem, hogy sokkal inkább érezni fogjátok ezeket a változásokat, függetlenül attól, hogy a naptár éppen 2008-at kezdett mutatni.  Nem hiszem, hogy ezen múlik…

Mindig is érdekes kérdés/probléma, ha az ügyfél számára nemcsak szállítanunk kell egy kész SharePoint-megoldást, hanem nulláról megtervezni s felépíteni is az architektúrát. Persze annak is megvannak a szépségei, ha egy már bevezetett szerverre/farmra kell újabb komponenseket készítenünk, de most nem erre szeretnék kitérni, hanem a teljesen zöldmezős projektekre.

Tegyük fel tehát, hogy az ügyfél még nem rendelkezik SharePointtal, s a mi feladatunk a fizikai és logikai architektúra megtervezése is.

Első lépés természetesen az üzleti igények felmérése: funkcionálisan mit szeretne az ügyfél. Mit szeretne most, s mik a tervei a jövőre nézve.

Emellett fontos a várható terhelést is figyelembe venni. Néhány példa:

• Telephelyek száma
• Felhasználók várható száma
• Intranetes vagy internetes környezet kiépítése a cél?
• Várható adatmennyiség (tárolt dokumentumok száma, átlagos mérete, stb.)
• Várható terhelés: elérés/nap, lekérések száma/látogatás, stb.
• A fenti (és egyéb) mutatók várható növekménye

Ezen adatok birtokában már elindulhatunk a tervezés útján. De vajon milyen eszközeink vannak, ha nem csupán “hasraütésszerűen” szeretnénk hardvereket vásárolni? Először is, a saját tapasztalat ebben az esetben is előnyt jelent. Ha van viszonyítási alapunk, sokat segíthet, egyrészt a tervezésben, másrészt a becslés pontosításában is.

Másodszor pedig rendelkezésünkre állnak különféle eszközök, melyek segítenek a döntésben. Nagyon fontos azonban arra figyelni, hogy ne alapozzunk döntéseket csakis és kizárólag ezen eszközök ajánlataira! Két ilyen “capacity planning” eszközt szeretnék megemlíteni:

• System Center Capacity Planner: https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1602
• HP ProLiant Sizer for Microsoft Office SharePoint Server 2007: http://h71019.www7.hp.com/activeanswers/Secure/548230-0-0-0-121.html

Mindkét eszközről elmondható, hogy nagy segítség a becslés során, ám óvatosan kell bánni az általuk adott eredményekkel. A SCCP például mininálisan 2 db. Web Front-End szervert ajánl egy háttér SQL kiszolgálóval, sőt ami ennél is megrázóbb: a memóriaigény becslését nem végzi el, fix értékekkel dolgozik: SQL 16GB, WFE 8GB… Így például 1 felhasználós, minimális terhelésnek (10GB content database) kitett farm is 3 kiszolgálóból áll, 16GB illetve 8GB memóriával…

 Másik limit az eszköz béta verziójában, hogy 100e felhasználó és 2TB adatmennyiség jelenti a felső korlátot számára, ennél magasabb értékekkel nem tud számolni.

Így ha valóban éles becsléseket szeretnénk alapozni ezekre az eszközökre, nem árt odafigyelni. Egyrészt építeni korábbi tapasztalatainkra, másrészt összevetni a két eszköz értékeit egymással (lehetőség szerint harmadik, negyedik forrásból származó értékekkel/ajánlásokkal is). Eddigi tapasztalataink azt mutatják, hogy ezek az eszközök iránytűként szolgálhatnak, de térképet nem adnak a kezünkbe…