2008. október havi bejegyzések

IIS 7 migráció: Request is not available in this context

Az elmúlt időszakban több alkalmazást migráltunk Windows Server 2008-ra és IIS 7-re. Volt olyan, amelyik csont nélkül működött az új környezetben is, volt olyan, amelyiknél a web.configot kellett módosítani és bizony volt olyan is, ahol hozzá kellett nyúlnunk a forráskódhoz.

Az egyik alkalmazás, miután áttettük IIS 7-re, az első induláskor sárga halált halt Request is not available in this context üzenettel. A jelenség nem egyedi, sikerült belefutnunk a 26 breaking change egyikébe:

16) It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax

Lehetséges megoldások:

  1. Az application pool átváltása Classic módba Integrated helyett. Ez persze egy gyors megoldás, de olyan lenne, mintha egy új autó karosszéria alá régi motort tennénk. Na nem olyan nagyon régit, de azért van különbség. Nem tetszett ez a megoldás.
  2. Az alkalmazás módosítása, hogy ne használjuk a Request objektumot az Application_Start eseménykezelőben.

Végül a második megoldás mellett döntöttünk, ezért több helyen kellett módosítanunk a kódot. Az egyik helyen a Request.ApplicationPath értékre volt szükségünk, amit gond nélkül át tudtunk írni HttpRuntime.AppDomainAppVirtualPath hivatkozásra, és ezzel megszűnt a probléma, örültünk.

Egy másik esetben azonban kifejezetten az volt a cél, hogy az alkalmazás indulásakor futtassunk olyan kódot, amelynek a Context objektumra is szüksége volt. Belefirkálunk a logba, ha a a web.configban debug beállítások szerepelnek, de persze csak éles környezet esetén, fejlesztés közben, amikor lokálisan jönnek a kérések, akkor nem:

    if( ( !this.Context.IsCustomErrorEnabled || this.Context.IsDebuggingEnabled ) && !this.Context.Request.IsLocal )
    {
        // Írás a logba...
    }

Itt tehát mindenképp szükségünk volt a HttpContext objektumra, de a kódot nem futtathatjuk az Application_Startban, hanem csak az Application_BeginRequestnél. Végül ez lett a megoldás, az InitializeFirstRequest metódust meghívjuk az Application_BeginRequestből:

    private static object initializationLock = new object();
    private static bool initialized = false;

    private void InitializeFirstRequest()
    {
        if( initialized )
        {
            return;
        }

        lock( initializationLock )
        {
            // Kód futtatása első alkalommal itt...

            initialized = true;
        }
    }

Természetesen elgondolkodtunk azon is, hogy mennyire fontos ez a funkció ahhoz, hogy minden egyes kérés feldolgozását lassítsuk valamennyivel miatta. Azután eszünkbe jutott, hogy hány alkalmazást láttunk már debug módban futni éles környezetben… 🙂

SQL Server Analysis Services szkriptelése – screencast

Áttekintés

Az adatbányászati feladatok megoldásához nem elég a T-SQL kifejezőereje, helyette a Data Mining Extensions (DMX) nyelvet használhatjuk. A két nyelv között óriási a hasonlóság – a DMX a T-SQL kiterjesztéseként is felfogható – mindkettőben találunk az adatok szerkezetére (data definition statements) és az adatok kezelésére (data manipulation statements) vonatkozó utasításokat.

Az Analysis Services adatbázis objektumainkat a megszokott CREATE, ALTER és DROP utasításokkal kezelhetjük, létezik például CREATE MINING STRUCTURE és ALTER MINING MODEL utasítás. Miután létrehoztuk a mining structure és mining model objektumainkat, a következő lépés a modell betanítása, azaz feltöltése adatokkal, melyhez az INSERT INTO utasítást használhatjuk. Végül a betanított modellt a SELECT utasítással kérdezhetjük le, melynek számos formája közül prediktív elemzési feladatokhoz valószínűleg legtöbbet ezt fogjuk használni:

    SELECT [TOP <row count>] <select expression list> 
    FROM <model>
    [
        [NATURAL] PREDICTION JOIN 
        <source data> AS <alias>
        [ ON <column mapping> ]
        [ WHERE <filter expression> ]
        [ ORDER BY <expression> ]
    ]

Az Analysis Services teljes körű szkriptelésére az Analysis Services Scripting Language (ASSL) használható. Az ASSL a szabványos XML for Analysis (XMLA) API-t használja a parancsok és paramétereik leírására, melyeket SOAP protokollon keresztül, TCP vagy HTTP felett küldhetünk el a szervernek. Mindegy, hogy OLE DB, ADO, ADOMD.NET vagy bármilyen más kliensből fordulunk a szerverhez, végső soron a provider XMLA-t állít elő, ez ugyanis az Analysis Services platform- és nyelvfüggetlen kommunikációs protokollja.

Első lépések

Szkriptek írásához nagy kezdőlendületet kaphatunk, ha Management Studioban megnyitjuk a Template Explorer ablakot és átváltunk az Analysis Services Templates csoportra, itt ugyanis 30 DMX és 18 XMLA szkript sablon segíti a leggyakoribb feladatok megoldását.

DMX szkriptek esetén további segítség az IntelliSense támogatás, illetve hogy a sablon megnyitása után a Query menüben a Specify Values for Template Parameters menüpontra kattintva gyorsan megadhatjuk a szükséges paramétereket.

Jó tudni

Az XMLA szkriptek írását segíti, hogy amikor a Management Studioban Analysis Services objektumokon vagy a Properties ablakban kattintunk a Script gombra, szintén XMLA szkriptek keletkeznek. Ezeket a szkripteket legegyszerűbben az SQL Server 2008 Integration Services vagy a példa programok között megtalálható ascmd.exe segítségével futtathatjuk, sőt akár saját alkalmazásainkba is beépíthetjük őket az ADOMD.NET provider segítségével.

Demó

A demóban áttekintjük az SQL Server Management Studio szkripteléssel kapcsolatos szolgáltatásait: szó esik az MDX, DMX és XMLA nyelvű szkriptek írásáról, az IntelliSense szolgáltatásról, a Template Explorer ablakról, az automatikus szkript generálás módjáról és természetesen a szkriptek parancssorból történő futtatásáról. A videó a képre kattintva megtekinthető böngészőben vagy a kép alatti linkre kattintva letölthető.

SQL Server Analysis Services szkriptelese screencast

Demó letöltés: SSAS_szkriptelese_(Balassy_Gyorgy).wmv (14:19, 61.6 MB)

További információk

 

Mi kell a .NET Frameworkből?

Igazat kell adnom azoknak, akik szerint a .NET Framework óriási és képtelenség ismerni az egészet alfától omegáig. Már az is jó kérdés, hogy a Frameworkben található számos technológia közül egyáltalán melyiket érdemes megtanulni, mire lesz szükségem? Scott Hanselman kérdőíve ad néhány tippet a kérdés megválaszolásához.

Brad Adams összesítése szerint a .NET Framework 1.0 3581 típussal indult 41 szerelvényben. A 3.5 verzióra a szerelvények száma 2.5-szeresére nőtt (98), a típusok száma megháromszorozódott (11417). Patrick Smacchia szerint a még nagyobb számokról van szó. Tippelni sem merek, mi lesz a 4.0-ban. Korábban azt lehetett mondani, hogy időnként jött egy-egy technikai bumm, ami után lassan csitult el a porfelhő és eltartott egy darabig, míg a fejlesztői társadalom megemésztette. Mostanra azonban a Microsoft átment szőnyegbombázásba, nincs olyan hónap, hogy ne jelenne meg valamilyen újdonság és már képben lenni is nehéz, nem hogy elsajátítani az új technológiát. Személy szerint jobban örülnék, ha új funkciók helyett a régieket tökéletesítenék, de nincs mese, szelektálni kell. Ha csak a webfejlesztést nézzük, ki tudja megtanulni az ASP.NET MVC, Dynamic Data, ADO.NET Data Services ÉS a Silverlight használatát?

Ezért örültem MS RD kollégám, Scott Hanselman házi felmérésének, amiben 14 technológiáról kérdezte meg a résztvevőket, hogy használják-e vagy sem. Egyetlen hét alatt közel ötezer válasz jött, ebből már érdemes statisztikát készíteni, íme az eredmény:

Scott_Hanselman_NET_subsystem_survey_results

Az nem lep meg, hogy a CardSpace a sor végén kullog, de az igen, hogy az MVC, az EF és az ADO.NET Data Services ilyen magas. Még akkor is, ha a publikáló blog olvasói valószínűleg az átlag feletti érdeklődésű és kísérletező fejlesztők és emiatt komoly fenntartással kell kezelni az eredményt. Hazai viszonylatban még a WCF sem végezne ilyen jó eredménnyel szerintem, pedig már közel két éve elérhető.

Mi a véleményetek?

Hova tűntek a régi devPortalos anyagok?

Mint biztosan sokan észrevettétek, a devPortal néhány hónapja teljesen megújult, új vason, új infrastruktúrán, új szoftver szolgálja ki a kéréseket, sőt a szerkesztő gárda is teljesen megújult és a szerkesztési alapelvek is alkalmazkodtak a megváltozott igényeknek. Ideje volt már.

Ezzel együtt azonban az összes régi devPortalra mutató URL meghalt, ami sajnálatos mellékhatása egy ilyen migrációnak. Mivel a régi rendszer 5 éves életciklusa alatt számos rendezvény, esemény, cikk, hír, példakód és induló készlet anyagainak tárhelyévé vált, és azok letöltésére mind a mai napig van igény, azok továbbra is elérhetőek a http://archiv.devportal.hu címről indulva. Sajnos előfordulhat, hogy itt-ott nem működik egyik-másik hivatkozás, ekkor némi kreativitással manuálisan ki kell cserélni az URL elején a “www”-t “archiv”-ra és újra próbálni.

Személy szerint nem tudom, hogy meddig fog élni ez az archívum, majd az illetékesek eldöntik, hogy meddig célszerű életben tartani. Mivel folyamatosan érkeznek kérdések azzal kapcsolatban, hogy az induló készletek anyagait hol lehet megtalálni, ezért azokat átmigráljuk a www.msdnkk.hu oldalra, az MSDN Kompetencia Központ saját honlapjára is. Itt már egyszerűen megtalálhatóak a következő induló készletek:

Az ASP.NET 2.0 Induló Készlet pedig egyelőre az archív devPortál címen keresztül érhető el.

 

Varázsoljunk connection stringet!

Teljesen nyilvánvaló, hogy a connection stringek nulláról történő megírását nem halandók számára találták ki, mégis újra és újra látok előbb lelkesen próbálkozó, majd később hevesen káromkodó kísérletezőket. Íme két jól bevált módszer a connection string összevarázslására – és persze egy ráadás!

1. ConnectionStrings.com

Már egy ideje működik és nagyon jól használható forrás a www.connectionstrings.com oldal. Semmi bejelentkezés vagy bonyolult menü, az ember hamar megtalálja, amit keres, pedig jelen pillanatban 309 connection string között kell tallózgatni keresés nélkül. Már van benne SQL Server 2008 oldal is, ahol még arra is kitérnek, hogy CLR tárolt eljárásból hogyan kell context connectiont használni.

2. UDL fájl

A varázslósabb megoldás, hogy létrehozunk a gépünkön egy üres fájlt .udl (Universal Data Link) kiterjesztéssel, ami így fog megjelenni:

.udl kiterjesztésű állomány a desktopon

Ha duplán rákattintunk, máris megjelenik a szokásos beállító ablak:

UDL Properties ablak

Kattintgassunk lelkesen, majd zárjuk be az ablakot az OK gombra kattintva. Az elkészült connection stringet az .udl fájlban találjuk, nyissuk meg Notepaddel.

+1 Ráadás fejlesztőknek

Aki szeret kódolni, feldobhatja a fenti beállító ablakot saját kódból is. Referenciát kell adni az ADODB.DLL-re és az MSDASC.DLL-re, majd az MSDASC.DataLinks osztály PromptNew vagy PromptEdit metódusát lehet használni. Íme egy rövid példa Dan Mayertől a CodeProjecten.

Jogosultság-szabályozás SQL Server Analysis Servicesben – screencast

Azt vettem észre, hogy az SQL Server relációs adatmotorját ismerő és használó fejlesztők és üzemeltetők közül sokan fenntartásokkal kezelik az SQL Server Analysis Servicest. Pedig a termék jó, fejlesztők nagyon gyorsan összekattintgathatnak vele üzleti intelligencia megoldásokat és üzemeltetői szemmel sem egy kimondottan bonyolult termék. Kedvcsinálóként készítettem néhány screencastot az SSAS-ről.

Áttekintés

Az SQL Server Analysis Services (SSAS) hozzáférés szabályozása az SQL Server más komponenseitől független és aránylag könnyen átlátható: a Windows felhasználóinkat vagy inkább csoportjainkat szerepkörökhöz rendelhetjük, melyekre meghatározhatjuk, hogy az adatbázis mely objektumát érhetik el.

Az SSAS kétféle szerepkört ismer: kiszolgáló szintű és adatbázis szintű szerepkört. Kiszolgáló szinten csak egy Server Administrators szerepkör létezik, amely felhasználó ennek tagja, az tetszőleges objektumhoz hozzáférhet és tetszőleges műveletet végezhet az adott SSAS kiszolgáló példányban. Noha ez a felhasználói felületen nem látszik, alapértelmezés szerint az operációs rendszer helyi Administrators csoportjának felhasználói tagjai lesznek ennek a szerepkörnek, de a telepítő is külön rákérdez, hogy milyen felhasználói fiókokkal szeretnénk üzemeltetni a kiszolgálót.

Az Analysis Services minden egyes adatbázisában definiálhatunk adatbázis szintű szerepköröket. Itt adhatunk Full control (Administrator), Process database vagy Read definition jogot az egész adatbázisra, de akár részletesen is megadhatjuk, hogy a szerepkör tagjai mely objektumokhoz férhetnek hozzá.

Első lépések

A jogosultságok állítását legegyszerűbben SQL Server Management Studioból végezhetjük el. Az adott SSAS példányhoz csatlakozva a kiszolgáló tulajdonságai között, az Analysis Server Properties ablakban a Security fülre kattintva tudjuk megadni a Server Administrators csoportba tartozó felhasználókat.

Ugyanebben az ablakban a General fülön, ha bekapcsoljuk a Show Advanced (All) Properties kapcsolót, van lehetőségünk állítani a Security BuiltinAdminsAreServerAdmins opciót.

Adatbázis szintű jogosultságokat az adatbázisban a Roles ág alatt adhatunk meg.

Jó tudni

Fontos, hogy Windows integrált hitelesítésről van szó, és hogy felhasználóknak közvetlenül nem adhatunk jogosultságot, csak szerepköröknek. Az SQL Server relációs motorjával ellentétben itt nem használhatunk tiltó (DENY) engedélyeket, így egy felhasználó eredő jogosultsága a szerepköreihez rendelt (megengedő, azaz ALLOW) jogosultságok uniója lesz.

Demó

A demóban áttekintjük a jogosultságok beállításának lehetőségeit mind az SQL Server Management Studioban, mind pedig a Business Intelligence Development Studioban. A demó videó a képre kattintva megtekinthető böngészőben vagy a kép alatti linkre kattintva letölthető.

Jogosultság-szabályozás SQL Server Analysis Services-ben screencast

Demó letöltés: Jogosultsag-szabalyozas_SSAS-ben_(Balassy_Gyorgy).wmv (11:30, 44.3 MB)

További információk