ÁghyBlog

Fejlesztő vagy? Sőt mi több: SharePOint fejlesztő? – Akkor a SharePointDevWiki-nek egészen biztosan hasznát veszed majd! 

Hivatalosan is bejelentették: az SP2 április 28-ra várható. Az SP2-vel érkező frissítések és javítások listája itt található.

A SharePoint fejlesztők számára érdekes és izgalmas hír, hogy Somasegar blogjában megjelent egy cikk a Visual Studio 10 SharePoint-támogatásáról. A (számomra) legizgalmasabb újdonságok (kiemelés tőlem):

In Visual Studio 2008, the supported workflow projects could be created only for lists and document libraries. In Visual Studio 2010, you’ll be able to create list and site level workflows as well as create aspx association and initiation forms.  And, as you would expect, the new Visual Studio 2010 designers can be used to create Web Parts, application pages, and user controls for a SharePoint site.

The WSP Importer enables you to quickly import existing SharePoint content and project wizards simplify solution development. For example, the wizard for Event Receivers allows you to simply select the events you want to handle and it will generate the necessary code and XML for you.    And, you will be able to quickly navigate and browse your Sharepoint site directly in Visual Studio with use the Server Explorer.

Érdemes a képeket is nagyban megnézni…

Októberben már írtam egy cikket arról, hogy milyen galibával szembesültünk egyik ügyfelünknél a .NET framework 3.5 SP1 telepítése után. A sztori azóta is “kísért”, vissza-visszatér a probléma/kérdés, nem hagy nyugodni.

A MSFT MCS-től, illetve angol blogom egyik kommentjében kaptam tippet, ami arra vonatkozott, hogy a híres-hírhedt loopback check okozhatja a problémát. Ha nem lennék olyan, amilyen vagyok, nyugodtan hátradőlhettem volna, azzal a tudattal, hogy megvan a megoldás, ha már egyszer “mindenki ezt mondja” – ám nem ezt tettem: elkezdtem utánajárni a dolognak, hogy vajon tényleg ez lehet-e a megoldás (mindenesetre gyanús, ha több helyről is ugyanaz a javaslat érkezik), és ha igen, akkor pontosan miért is.

Néhány tény:

• A Records Center problémára október elejétől kerestük a megoldást, blogbejegyzésem október 31-én született a tanulságokról.
• Ugyancsak a SharePoint és a .NET framework 3.5 SP1 kapcsolatáról október 30-án jelent meg egy cikk, amely ugyan nem közvetlenül a Records Centerről szól, de a loopback check lényegét jól leírja (kiemelés tőlem, a későbbiekben még fontos lesz):

“The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server.”

• A jelentleg letölthető .NET framework 3.5 SP1 2008. november 18-án került publikálásra:

Szóval a lényeg: a loopback check kikapcsolása akkor segíthet, ha lokálisan, a szerveren belüli hívások történnek, hiszen ezek okozhatnak galibát. Igen ám, de a Records Center esetében mi bizony távoli gépekről is teszteltünk, nemcsak a MOSS szerverről! Ebben az esetben csakis akkor lehet tehát gond, ha a háttérben, a Records Center működése közben történnek a szerveren belüli hívások. Nézzünk tehát utána!…

A Records Center működése dióhéjban, felhasználói oldalról: a Records Center maga egy speciális webhelysablonból (site template) jön létre, amelyet célszerű legalább külön webhelycsoportba (site collection) tenni, de több szempont (például adatbázis-optimalizálás) is a szeparált webalkalmazás (web application) mellett szól. Arra is van azonban lehetőségünk, hogy teljesen különálló farmon lévő Records Centert használjunk.

Miután létrehoztuk a Records Center webhelyet, bekonfiguráltunk néhány dolgot (pl. records routing, amely azt mondja meg, milyen tartalomtípusú dokumentumok melyik dokumentumtárba kerüljenek), a produkciós környezetben is beállítjuk, hogy onnan ezt az adott Records Centert szeretnénk használni. Ez a beállítás a Records Center egy speciális web service-ének (_vti_bin/officialfile.asmx) megadását jelenti – ennek később még nagy jelentősége lesz.

Látszólag tehát amikor egy dokumentumot szeretnénk beküldeni a Records Centerbe, a RC egy webszolgáltatása kerül meghívásra:

Ha azonban jobban megnézzük, mi történik ilyenkor, a következőt láthatjuk: a “Send To –> My Records Center” menüpont kiválasztásakor nem közvetlenül a Records Center web service kerül meghívásra, hanem az adott produkciós környezet LAYOUTS mappájában található SendToOfficialFile.aspx. Ezután a következő hívások történnek a háttérben:

Vagyis az ASPX mögötti code behind-nak köszönhetően először jónéhány SharePoint API-hívás történik, s csak ezután kerül a vezérlés az officiealfile.asmx web service-hez! Ha pedig a Records Center ugyanazon a szerveren (farmon) található, ahol a produkciós környezet, akkor ez az áthívás a webszolgáltatásba lokális hívás lesz! – Így már érthető, hogy a loopback check kikapcsolása miért jelenthet megoldást a problémánkra!

Sőt, ez arra is magyarázatot ad, miért kaptuk ugyanezt a hibaüzenetet, ha az adott farmon újabb Records Centert hoztunk létre, s oda próbáltuk küldeni a dokumentumokat.

Ha pedig távoli (másik szerveren/farmon található) Records Centerbe küldjük a file-okat, akkor annyi a különbség, hogy a SendToOfficialFile.aspx lokálisan, a produkciós környezet LAYOUTS mappájából kerül meghívásra, az OfficialFile.asmx webszolgáltatás viszont a Records Center szerverén található példány, így az áthívás távoli, nem pedig lokális.

Úgy tűnik tehát, a rejtélyes probléma megoldódott, teszteléseim és a fenti nyomozás is ezt támasztják alá. Sajnos a hibaüzenetek nem túl egyértelműek, az itt kapott üzenet (”The DevRC Records Center could not be found or accessed.”) például több más, általánosabb esetben is előfordul. Ugyanezt kapjuk például, ha a konfigurálás során a Records Center URL-jét rosszul állítjuk be, illetve akkor is, ha az adott felhasználónak nincs joga file-t küldeni a Records Centerbe. Ennek oka, hogy a Records Center mögötti hibakódok egy elég rövid enum-ban vannak definiálva, a következő értékekkel:

Gyakran szoktam azzal zárni írásaimat, hogy “Folyt. köv.” – Igazából most azt remélem, hogy ebben az esetben nem lesz folytatás, és nem derül ki valami újabb turpisság a dologgal kapcsolatban… (Persze ha Te ilyet tapasztalsz, ne kímélj, mindenképp írd meg!…)

Miközben időm nagy részét lefoglalja pár hetes kislányom, a nagyvilágban egymást követik az érdekes események és bejelentések. Emellett épp különféle doksikat review-zok, így az eseményeket már követni sem egyszerű, up-to-date beszámolni róluk pedig…
De íme most “ömlesztve” az elmúlt néhány nap (hét) legfontosabb SharePoint vonatkozású hírei:

• SharePoint Dispose Checker: A SharePoint fejlesztés, API használat közben gyakran dispose-problémák merülnek fel, az. Ezek nemcsak a fejlesztők életét keserítik meg, de a kód minőségén keresztül végső soron a felhasználók, megrendelők isszák meg a dolog levét. Szerencsére január 30. óta publikusan is elérhető az SPDisposeChecker:

“SPDisposeCheck is a tool to help you to check your assemblies that use the SharePoint API so that you can build better code. It provides assistance in correctly disposing of certain SharePoint objects to help you follow published best practice. This tool may not show all memory leaks in your code. ”

• FAST Search integráció: Las Vegasban, a FASTforward’09-en hivatalosan is bejelentésre került: a SharePoint “14” (vagyis a következő verzió) már tartalmazni fogja az úgynevezett “FAST Search for SharePoint”-ot:

“FAST Search for SharePoint will combine high-end search with the broad portal, collaboration, content management and business intelligence capabilities of SharePoint.”

• Best Practices Conference: Sikeresen lezajlott San Diego-ban a második Best Practices Conference. Folyt. köv. Londonban, április elején.
  (Több e-mailt is kaptam ezzel kapcsolatban, így akik esetleg aggódnának: nem, nem marad nélkülem az akkor alig 2,5 hónapos kislányom, nem fogok távszoptatni, és béranyát sem fogadtam. A család is utazik velem - a konferencia szervezőinek hála, a meghívás része volt az is, hogy számukra is biztosítanak mindent, ha elfogadom az előadói felkérést.)

Folyt. köv.

Mivel a héten szabadságon vagyok, ráadásul jó távol otthonról, rendkívül gondosan ügyelek arra, nehogy túl sokat legyek gép előtt Azt hiszem, jó eredményt értem el: hétfő óta összesen kb. 15 percet töltöttem a laptopom mellett…

Közben persze az élet nem áll meg, sőt. Most zajlik a TechEd Developer Conference Barcelonában. Amint hazaérek, mindenképp jelentkezem a részletes hírekkel, újdonságokkal, ám most villám stílusban két bejelentés, melyeket igencsak vártunk már:

• Visual Studio 2010 Tools for SharePoint: Server Explorer, WSP import, Visual web part designer, packaging explorer, stb.
• SPDisposeCheck: “Many SharePoint API’s allocate COM based memory that is not released by CLR garbage collection and must be released by calling the Dispose() methods. (…) SPDisposeCheck will open your custom compiled assemblies recursively and validate them against the Microsoft published guidance. The output from the tool will contain messages that may indicate the SPSite and SPWeb Dispose() methods guidance are not being followed in the customers source code.“

Folyt.köv….

Egyik ügyfelünknél érdekes és roppant bosszantó problámával szembesültünk.

A környezet: 64 bites Windows Server 2003 SP2, rajta MOSS 2007 Enterprise, és természetesen .NET framework 2.0 és 3.0. Az SQL 2005 külön szerveren. Az egész egy fejlesztői tesztszerver, rajta kb. 1 éve folyik a munka: ez jelenti az integrációs “hidat” közöttünk és az ügyfél között: minden új fejlesztést először ide szállítunk, itt folyik a tesztelés, majd amikor funkcionálisan rendben a dolog, akkor kerül át az éles környezetbe.

Egyik új fejlesztésünkben szerettük volna használni a Linq4SP-t, ehhez pedig szükségünk volt (lett volna) a .NET framework 3.5-re is. A mi fejlesztőkörnyezetünkben csodaszépen működött minden, irány az ügyfél, a fent nevezett környezettel. Az üzemeltetés fel is készült: feltelepítette a .NET framework 3.5 SP1-et, hogy előkészítse számunkra a terepet. A solution is felment, szépnek tűnt a világ, ám a tesztelés során az eddig működő Records Center minden kérésre hibát dobott: The DevRC Records Center could not be found or accessed.

A Records Center konfigurálási hibát kizártnak tekinthettük, hiszen korábban működött, és a beállításait senki nem módosította. Azonban egészen biztosnak kellett lennünk abban, hogy nem RC oldali a hiba, nekiálltunk hát kísérletezni:

1. Átütöttük a Records Center beállításait, hogy egy másik MOSS tesztrendszer Records Centerébe küldje a dokumentumokat. Hibaüzenet ugyanaz.
2. Egy korábbi projektünk során szükség volt arra, hogy a beépített Records Center Web Service-t saját implementációra cseréljük. Ezt a web service-t élesítve az adott, problémás szerveren, továbbra is ugyanaz a hibajelenség. A web service-hez nem is érkezett meg a kérés.

Ez a két tény egyértelműen azt bizonyítja, hogy a hiba a dokumentumok elküldésekor lép fel, s nem azok RC-beli fogadásakor. De hogy valóban mi okozta, azt még bizonyítani kellett.

Leszedtem tehát a .NET framework 3.5-öt, s maradt a 3.0 és 2.0 - hibaüzenet továbbra is. Ez tehát nem elég, de feltételeztük, hogy a framework telepítése okozta a galibát, ezért mentem tovább: a 3.0 és a 2.0 is lekerült a gépről, majd újra fel. - Az ötlet jónak tűnik, ám ez a lépés ugye eléggé “belemászik” a SharePoint lelki világába, hiszen ezek adják a SP egyik legfontosabb alapját. Nem meglepő tehát, ha a framework-ök cseréje után a SharePoint megadta magát, az IIS nem tudja feldolgozni a kéréseket, s a Config Wizard sem segít.

Első lépés tehát: ASP.NET 2.0 engedélyezése az IIS-ben. A telepítés utáni alapértelmezés ugyanis Prohibited…

Haladunk, haladunk, a Central Administration már elérhető, a tartalmi oldalak azonban HTTP 403 hibát dobnak, IISRESET után is. A site tehát már elérhető, de valahol authentikációs hibába fut a kérés, ráadásul még a “háttérben” - tehát vagy IIS, vagy SQL eléréssel lesz a gond. Mivel az SQL-hez nem volt közvetlen hozzáférésünk (lévén ügyféloldali éles SQL szerverről van szó), a MOSS admin felhasználónak pedig adatbázis létrehozásához sincs joga, új webalkalmazást (web application) nem tudunk létrehozni, hogy teszteljük: az működne-e. Meglévő webalkalmazást viszont tudunk kiterjeszteni (extend web application): válasszuk tehát ezt az opciót, s a meglévő (de egyelőre működésképtelen) http://dev:80 környezetünket terjesszük ki, mondjuk az Intranet zónában, a http://dev:12345 portra. Néhány pillanat múlva azt láthatjuk, hogy a korábbi site-ok az új címen gond nélkül, ugyanúgy elérhetők, mint az egész “móka” előtt. Sőt… Feléledt az eredeti, http://dev:80 is!…

Hmmm, vajon ennek mi lehet az oka? Adatbázis-szinten a SharePoint valami olyan konfigurációs hibába futott, amely miatt az extend előtt nem tudott “mit kezdeni” a kérésekkel, most pedig az extend hatására ez a konfigurációs beállítás a helyére billent.

Rövid próba: a Records Center is működik… A http://dev:12345 törlése után tehát ismét előállt ugyanaz a környezet, mint a .NET framework 3.5 SP1telepítése előtt. - Kezdődhet a reprodukció!

Némileg módosított forgatókönyvet követtem azonban: először az SP1 nélküli, “sima” .NET framework 3.5-öt telepítettem a gépre. Láss csodát: a Records Center működik továbbra is gond nélkül. Amint viszont felkerül az SP1, a Records Center meghal.

A tanulság tehát: 64 bites környezetben, MOSS Enterprise és .NET Framework 3.5 SP1 összeakad(hat). Hogy pontosan mi történik a háttérben, és milyen egyéb feltételek játszanak még közre a hiba bekövetkezésében, azt Redmondban már vizsgálják. Reméljük, hamarosan lesz hotfix is…

Mint bizonyára sokan tudjátok, fejlesztő kollégáimmal az utóbbi hónapokban többek között a Linq4SP -n dolgoztunk. A Linq4SP nem más, mint egy írható-olvasható LINQ provider a SharePoint 2007-hez, mellyel az objektummodell és a CAML lekérdezések “szépségei” (értsd: nehézségei) kerülhetők el: többek között támogatja a listaelemek és dokumentumok, mappák, tartalomtípusok, különféle oszloptípusok, stb. kezelését.

A LInq4SP  RC1-et néhány perce tettük online elérhetővé: letöltés után játszhatsz vele, tesztelheted, próbálgathatod az erejét - szerintem megéri! Ha valaha is fejlesztettél SharePoint alá, érteni fogod, mire gondolok…

Letöltés után egyszerűen másold fel a kicsomagolt file-okat a SharePoint szerveredre (WSS 3.0 vagy MOSS 2007) úgy, hogy a Generátorhoz tartozó EXE file a DLL-lel azonos könyvtárban legyen (ahogyan a ZIP file-ban is találod).

A Generátor indítása után válaszd ki a megfelelő site collection-t és site-okat (webhelyeket), melyekkel dolgozni szeretnél. Ekkor máris kiválaszthatod a szükséges listákat és dokumentumtárakat, s már generálhatod is a LINQ context-et. Ezután a generált forrásfile-t és a kapcsolódó DLL-t csatold a saját Visual Studio projektedhez, s máris kész!

Mit szólsz?

A LInq4SP  dokumentációja egyébként éppen készülőfélben van, de egy egyszerű CHM help-et már találsz a letölthető ZIP file-ban. Sőt, emellett példa site-ot és teszteseteket is,  melyek segítséget nyújthatnak az induláshoz.

Maga a Linq4SP története, fejlesztése is igen érdekes történet, ígérem, legközelebb erről is mesélek!…

Amikor telepíted az OBA Composition Toolkit-et, talán Te is belefutsz a múltkori cikkemben szereplő Provisioning Error-ba. Még egy kis adalék: jó esetben az OBACT telepítése közben a MOSS Central Administrator webalkalmazásának web.config file-jába az alábbi bejegyzések kerülnek:

<add key="OBAAdministration" value="http://obademo:12345/CompositionServer/Administration.asmx" />

<add key="OBACompositionInstallerPath" value="C:\Program Files\CompOBARefToolkit\" />

Ha ez utóbbi hiányzik, a megfelelő adatbázisbejegyzés üresen marad, vagyis a provisioning ezért hiúsul meg… Már csak az a kérdés, hogy miért nem kerül be ez a tag a web.config-ba…

OK, eldöntötted: szeretnéd kipróbálni az OBA Composition Toolkit v2-t - de hogyan is érdemes elindulni?

Először is, az MSDN-ről letölthető az eszköz, különféle dokumentációkkal együtt. Ott van például a Setup Guide, amely mind a szerver-, mind a kliensoldali követelményeket részletesen leírja. Ha mindezt előkészítetted, s pontosan követed a telepítési útmutatóban leírtakat, máris használhatod az OBA Composition Toolkit-et (OBACT). Sőt, a telepítéskor lehetőségünk van referencia komponensek azonnali alkalmazására, kipróbálására is.

Teljesen jó, de hogyan hozhatunk létre saját komponenseket? Természetesen erre is van lehetőségünk (lásd Developer Guide) - de mindez alapos körültekintsét igényel, hiszen néhány ponton elég gyakran elhasal a történet. Első alkalommal viszonylag nagy valószínűséggel abba a hibába botlunk, hogy komponensünk nem hajlandó Provisioned állapotba eljutni, beragad Queued státuszba. Mióta az OBACT-vel dolgozom, több környezetben is találkoztam ezzel a problémával (pl. BDC definíció, VSTO addin, stb. komponensek esetében is).

Némi nyomozás után az derült ki, hogy a probléma az adatbázis környékén van. Ha jobban beleássuk magunkat, azt látjuk, hogy a ComponentProvisioningJobInfo tábla FileSharePath mezője a mi komponensünknél üres, valamiért nem sikerült beállítani a provisioning során. A javításhoz tehát nyissuk meg az OBASERVERDB adatbázist, s manuálisan állítsuk be a megfelelő FileSharePath értéket (a megfelelő ZIP file elérési útja kerül ide). Ezután az adminisztrátori felületen újra adjuk ki a Resubmit for Provisioning utasítást.

Nos, az esetek többségében ez segít a problémán. Ám sajnos nem mindig. A végső megoldás, amely valamennyi esetben megoldja ezt a hibát: távolítsuk el a referencia komponenseket, majd magát az OBACT-t is, ezután pedig telepítsük újra a Composition Toolkitet. Ekkor indítsuk újra a Provisioning folyamatot a komponensünkre - tapasztalataim alapján ez az "agresszív" módszer minden esetben segít.

Az SSDS (SQL Server Data Services) ugyan még zártkörű Beta, ám múlt héten máris megjelent hozzá az SSDS SDK Beta első verziója. Ez egyrészt parancssori eszközt (Command Line Tool), másrészt az úgynevezett SSDS Explorert tartalmazza. Ez utóbbi eszköz a GET, POST, PUT, DELETE és Query műveletek hatékony és szemléletes megvalósítására szolgál.

Az SSDS Explorer ugyanakkor nem támogat minden funkciót, amely paranccsorból/saját kódból elérhető (pl. backup/restore, blob műveletek).

SSDS SDK letöltés itt.

Ma megjelent mindkettő:

• VS 2008 SP1 letöltés
• .NET Framework 3.5 SP1 letöltés

Egyik kollégám, a LINQ4SP projekt vezető fejlesztője, Leiszen Dani, sorozatot indított a LINQ4SP mélyebb fejlesztői-fejlesztési szépségeiről. Az első rész itt található: LINQ4SP - Query Evaluation:

“The evaluation of a Linq query is quite straightforward. The provider of the query source creates a new query object based on the given query expression, and returns it. When the client code tries to iterate through the results, the query object triggers the provider to evaluate the expression tree and to turn the tree into one or more CAML queries.”

Végre-valahára megjelent a VSeWSS 1.2, vagyis a Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, v1.2. A csomag újdonságai:

Visual Studio 2008 Project Templates

• Web Part
• Team Site Definition
• Blank Site Definition
• List Definition
• Empty SharePoint Project

Visual Studio 2008 Item Templates (items that can be added into an existing project)

• Web Part
• Custom Field
• List Definition (with optional Event Receiver)
• Content Type (with optional Event Receiver
• Module
• List Instance
• List Event Handler
• Template

Aki SharePoint fejlesztéssel foglalkozik, annak azt hiszem, azonnal kötelező…

A tegnapi nap/éjszaka folyamán publikussá vált egy újabb, igen hasznos site, melyet a Paul Andrew vezetésével a SharePoint Product Group hívott életre. Az MsSharePointDeveloper.com oldal .NET fejlesztőknek nyújt segítséget abban, hogyan indulhatnak (indulhattok ) el a SharePoint fejlesztés rögös útján. Számos link, hasznos cikk mellett egy összefoglaló WhitePaper, sőt fejlesztői virtuális gép image is letölthető.

Azt hiszem, a site szlogenje magáért beszél: “Do Less. Get More. Develop on SharePoint.“

.NET fejlesztőként bizonyára Te is találkoztál már a Visual Studio Extensibility (VSX) kifejezéssel. Akár “egzotikus” számodra ez a kifejezés, akár profinak érzed magad a témában, javaslom, hogy gyere el jövő héten a VSX Turnéra, ahol a szakma redmondi nagymestereivel találkozhatsz!

Novák István MVP kollégám-barátom, a téma hazai szakértője lesz a “házigazda”, neki köszönhetjük, hogy ez az esemény Budapestre is megérkezhetett.

Örömmel hozom a hírt: elkészültünk a LINQ4SP Beta1 verziójával, így mostantól bárki letöltheti és kipróbálhatja. A telepítőkészlet mellett részletes Release Notes is található (angol nyelven).

Ha bármilyen észrevételed, ötleted vagy javaslatod van, kérlek, oszd meg velem itt, vagy a molnar.agnes{at}lmsolutions.hu címen.

Ha pedig hibát találsz, és szeretnéd közvetlenül a fejlesztők felé jelezni azt, megteheted a projekt bug trackerén: bugs.lmsolutions.hu - csak válaszd ki a LINQ4SP projectet, és máris várjuk a visszajelzésed.

A végleges termék megjelenése után a legaktívabb tesztelőket jelentős árkedvezménnyel jutalmazzuk!

Az első publikus bejelentés és a Kódgenerátor óta számos igen pozitív visszajelzést kaptunk a LINQ4SP-vel kapcsolatban - itthonról és külföldről egyaránt. A kommentek, bejövő hivatkozások, e-mailek és telefonhívások mind azt mutatják, hogy világszerte felfigyeltek a termékre, s várják az első publikus megjelenést.

A Beta1 előtt azonban közzétettünk néhány olyan, rövid demót, amely a LINQ4SP használatának egyszerűségét mutatja be. Elsőként íme, egy SharePoint lista lekérdezése, vagy annak bemutatása, hogy lehet új elemet szúrni egy listába.

A felhasznált SharePoint listák az AdwentureWorks adatbázis néhány táblájának migrációjából születtek, az alábbi sémának megfelelően:

Hamarosan érkeznek a további videók: lookup mezők kezeléséről, elem törléséről, módosításáról, stb. - És persze a Beta1 is itt a küszöbön!…

Mintegy két napja letölthető a VS 2005 Extensions User Guide. A kapcsolódó VS 2005 Extension február óta érhető el, a Visual Studio 2008-hoz tartozó júniusra várható.

A User Guide az alábbi témákkal foglalkozik:

1. Starting out in SharePoint Development
2. Walkthrough of the VSeWSS User Interface including the WSP View
3. The Team Site Project
4. The Blank Site Project
5. The List Definition Project
6. The Web Part Project
7. The Workflow Projects
8. Project Item Templates
9. Best Practices with VSeWSS
10. Changes from 1.0 to 1.1

A VSeWSS 1.1 használatához az alábbi erőforrásokra van szükségünk:

1. Windows Server 2003 vagy Windows Server 2008
2. .NET Framework 3.0
3. Visual Studio 2005 Professional or greater
4. Windows SharePoint Services 3.0 SP1
5. Windows SharePoint Services SDK 1.3
6. Visual Studio 2005 extensions for .NET 3.0, Windows Workflow Foundation
7. Visual Studio 2005 extensions for Windows SharePoint Services 3.0, v1.1

Mivel a hét végére tervezzük a LINQ4SP Beta1 publikálását, lássuk a medvét: mit is tud ez a dolog? Elsőként a kódgenerátort szeretném bemutatni Nektek, amellyel megnyithatod a szükséges site-ot, kiválaszthatod a listákat, oszlopokat, lookup-okat stb., melyeket fel szeretnél használni, s máris mehet a generálás, s a kódfile azonnal megnyitható!

Ha érdekel, hogyan, ebben a rövid demóban megnézheted.

Ha foglalkozol SharePoint fejlesztéssel, valószínűleg Te is tapasztaltad már, hogy ez bizony nem túl egyszerű műfaj. Az elmúlt időszakban cégünkben arra helyeztük a hangsúlyt, hogy a korábbi projektek tapasztalatait összegyűjtve egy olyan objektum-réteget alakítsunk ki, amely az elkövetkező projektek, munkák során jelentősen megkönnyíti fejlesztőink életét.

Ennek eredményeképpen (többek között) megszületett a LINQ4SP: ez egy teljes mértékben saját LINQ implementáció, melyet a SharePoint fölé húzva hatékonyabbá, gyorsabbá és egyszerűbbé tehetjük fejlesztéseinket. Képzeld el például, hogy a LINQ segítségével ugyanúgy érhetsz el SharePoint listákban található adatokat, mintha azok egy egyszerű SQL táblában lennének…

További részleteket itt olvashattok.

Az első OBA demóban bemutattam, hogyan lehet OBA komponenseket egyszerűen szállítani, közzétenni. Most egy valódi, saját fejlesztésű példát is láthattok majd, amely különféle háttér-rendszerek alapján hoz létre dokumentumokat.

Vegyünk egy teljesen általános felhasználói igényt: automatikus dokumentumgenerálás, előre rendelkezésre álló információk alapján. Lehessen szerződéseket, specifikációkat, oktatóanyagokat, stb. előre definiált részekből, úgy, hogy a megoldás megfeleljen az alábbi követelményeknek:

• a felhasználók számára transzparens legyen az adatok forrása
• lehetőség szerint használjuk ki a rendelkezésre álló kliens alkalmazások erősségeit
• lehetőség szerint ne kelljen módosítani a háttér-rendszerek architektúráján

A Srácok segítségével összeraktunk tehát egy olyan OBA alkalmazást, amely a következőképpen épül fel: kliensoldalon egy VSTO AddIn segítségével a Word 2007-be épül, így a felhasználók egy általuk jól ismert felületbe ágyazva találkoznak az új funkcionalitással.

Az AddIn WCF-en keresztül (Windows Communication Framework) kommunikálnak az alsóbb rétegekkel. A legalsó szinten, adatforrásként maga a SharePoint helyezkedik el, a jelenlegi verzióban itt tárolunk mindent: az egyes fejezetek (Section) dokumentumtárakban, a hozzájuk tartozó metaadatok, ügyfelek és kapcsolattartók pedig listákban kerülnek tárolásra. (Természetesen más adatforrások beépítésére is van lehetőség.)

A WCF és a SharePoint között egy saját komponensekből álló LINQ4SharePoint réteget hoztunk létre: ez egy saját, egyedi fejlesztésű LINQ implementáció SharePoint-hoz, melyben összegyűjtöttük az eddigi projektjeink, munkáink tapasztalatait. A modul célja, hogy a fejlesztést hatékonyabbá tegye mind sebesség, mint komplexitás tekintetében. A LINQ4SharePoint első publikus verzióját még ebben a hónapban (2008. április) tervezzük elérhetővé tenni.

Lássuk tehát, hogyan működik az alkalmazás, a fejlhasználók szemszögéből (a demóhoz klikk a képre): A felhasználó az első blokkból kiválasztja a dokumentumtípust (Ajánlat, szerződés), majd kiválasztja a kategóriához tartozó Sections listából a megfelelő fejezeteket. A VSTO AddIn - a megfelelő rétegeken keresztül - felolvassa a fejezethez tartozó dokumentumot a háttérben található SharePoint dokumentumtárból.

Egy élő dokumentum azonban a benne található dinamikus adatok miatt lesz igazán élő. Ebben a példában ügyféladatokat (cég + kapcsolattartó) szúrhatunk be dokumentumainkba (cégnév, számlaszám, adószám, székhely, kapcsolattartó neve, beosztása, stb.) - természetesen az adatforrás nemcsak SharePoint lista lehet, de tetszőleges adatbázis (SQL, SAP, Oracle, MySQL, stb.) vagy Web Service is.

Az ügyfelekre vonatkozó adatokat a dokumentumba ágyazott property field-ek segítségével könnyedén beszúrhatjuk, s az előre definiált fejezetek is ide vonatkozó hivatkozásokat tartalmaznak. Amennyiben a legördülőből másik céget/kapcsolattartót választunk ki, az “Update contacts” funkció segítségével valamennyi ügyfél-mező értéke frissítésre kerül, így könnyedén lehetőségünk adódik módosításokra is.

Madarat tolláról, embert OBÁjáról - a demó-célok mellett cégen belül mi magunk is ezt a komponenst kezdtük használni, elsősorban oktatóanyagok, szerződések és árajánlatok készítésére. Ezzel együtt természetesen időnként fejlesztünk is rajta, úgyhogy érdemes figyelni, mert folyamatosan hozom majd a friss információkat.

Akit pedig érdekel a komponens működés közben is, az V. Architektúra Fórum felvételén azt is megláthatja.

Folyt.köv., Seattle-ből.

Március 27-én lesz a Visual Studio 2008 hazai termékbejelentő konferenciája, és abban a megtiszteltetésben van részem, hogy egy rövid előadás keretében bemutathatom egy megoldásunkat, amely már ezt az új terméket dicséri.

Egy nagyvállalati döntéstámogató workflow-ról van szó, melyet nemrégiben adtunk át SharePoint-alapokon: a teljes rendszert mintegy 12.000 felhasználó használja, a döntések a folyamatok végén pedig egy néhány fős bizottságnál futnak össze. Nagyon szép feladat, érdekes és értékes tapasztalatokkal - de ezekről bővebben a konferencián…

A napokban megjelent a WSS 3.0 SDK és a MOSS 2007 SDK újabb verziója, melyek többek között az SP1-gyel kapcsolatosan is tartalmaznak friss tartalmakat.

Scott Hiller blogjában találtam egy cikket, amelyben azt írja le, hogyan lehet garantálni egy oszlop egyediségét adott listán belül. A megoldás azért tetszik nagyon, mert nem egyedi oszloptípus létrehozásával oldja meg a dolgot, hanem egy másik oldalról közelít: egy policy-t definiál, amelynek engedélyezése után megadhatjuk, melyik oszlopra szeretnénk biztosítani az egyediséget.

A megoldás nagyon elegáns, azonban nemrégiben egy projekt kapcsán egy olyan problémába futottunk, amelyre a fenti ötlet nem volt elegendő. WSS 3.0-n kellett garantálni az egyediséget, azonban nem csupán egyetlen dokumentumtáron belül, hanem több library között is. A környezet: szerződésnyilvántartás egy ügyfélnél úgy, hogy a szerződések több dokumentumtárban helyezkednek el. A szerződésszámokat egy másik (humán) rendszer generálja, amely nincs szinkronizálva és összekapcsolva a WSS-sel - ezért a szerződésszám globális egyediségét annak begépelésekor kell biztosítanunk.

Milyen megoldást választottunk tehát? Adja magát, hogy valamiféle event handlerre van szükségünk, mégpedig olyanra, amely szinkron módon kapja el az értékadást: ha még nincs ilyen szerződésszám, mehet a dolog, egyébként dobjunk hibaüzenetet a felhasználónak. Az eseménykezelő pedig egy custom column definícióba épült be, vagyis készítettünk egy olyan egyedi oszloptípust, amely gondoskodik arról, hogy ha bárki értéket ad neki, a háttérben leellenőrzi a tárolandó értéket.

Az oszlop definiálása a TEMPLATE\XML\FLDTYPES_LMSolutions.xml file-ban történik, az alábbiak szerint:

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <FieldTypes>

   3:  

   4:    <FieldType>

   5:      <Field Name="TypeName">LMSolUniqueColumn</Field>

   6:      <Field Name="ParentType">Text</Field> 

   7:      <Field Name="TypeDisplayName">LM Solutions Unique Column</Field> 

   8:      <Field Name="TypeShortDescription">Unique Column</Field> 

   9:      <Field Name="UserCreatable">TRUE</Field> 

  10:      <Field Name="ShowInListCreate">TRUE</Field> 

  11:      <Field Name="ShowInSurveyCreate">TRUE</Field> 

  12:      <Field Name="ShowInDocumentLibraryCreate">TRUE</Field> 

  13:      <Field Name="ShowInColumnTemplateCreate">TRUE</Field> 

  14:      <Field Name="FieldTypeClass">LMSol.LMSolUniqueColumn,LMSol,Version=1.0.0.0,Culture=neutral,PublicKeyToken=0123456789ABFCDG</Field>

  15:      <Field Name="FieldEditorUserControl">/_controltemplates/LMSolFieldEditor.ascx</Field> 

  16:  

  17:      <PropertySchema> 

  18:        <Fields> 

  19:          <Field Name="UniqueColumnField" Type="Text" Hidden="TRUE"> </Field>

  20:        </Fields>

  21:      </PropertySchema>

  22:  

  23:    </FieldType>

  24:  </FieldTypes>  

A szinkron eseménykezelő pedig valahogy így néz ki:

   1:  using System;

   2:  using Microsoft.SharePoint;

   3:  namespace DocumentCounterEventHandler

   4:  {

   5:    public class DocumentCounterEventHandler : SPItemEventReceiver

   6:    {

   7:      public override void ItemUpdating(SPItemEventProperties properties)

   8:      {

   9:        // ...

  10:      }

  11:    }

  12:  }

Rendben, WSS alatt, globálisan működő megoldást találtunk, ám egy helyen még mindig hiányos, ha már nekiállunk, legyen kerek a történet: gondoskodjunk arról is, hogy tipizálni lehessen a unique értékeket. Vagyis ha valaki nemcsak a szerződésszámokra, hanem például termékkódokra is szeretné ráengedni ezt a feature-t, akkor ezt megtehesse a szerződésszámok mellett is. Viszont értelemszerűen a szerződésszámokat és a termékkódokat egymással nem szeretnénk összehasonlítani.

Azonosítsuk tehát azt is, hogy milyen scope szerint legyen egyedi az érték - ennek megoldására az oszlopunk létrehozásakor egy kódot is megadhatunk, amelyet a rendszer eltárol (pl. SZERZODES vagy TERMEK). Ezután, amikor új értéket adunk egy ilyen típusú oszlopnak, először megvizsgálja, hogy melyik kód tartozik ide, s az eseménykezelő azon belül vizsgálja az egyediséget. Kész tehát a saját, eseménykezelőn alapuló, globális unique oszlopunk. Ami még hiányzott a szerződésnyilvántartóból: minden szerződéshez (dokumentumhoz) attachmentként lehessen eltárolni különféle file-okat, például az aláírt, bescannelt változat képét, mellékleteket, stb. - De ez már egy következő cikk témája lesz…

Ha svájcibicska, akkor vágjunk is bele rögtön a közepébe. Az alapprobléma a következő: a cég egyik ügyfelénél state machine workflow-t fejlesztünk, melynek feladata röviden a vállalatvezetés döntéstámogatása. Mivel a workflow több helyen, többféle taskot dob a felhasználóknak, szükséges volt, hogy azok különféle módon jelenjenek meg, ezért custom ASPX formokat rendeltünk az egyes task content type-okhoz.

A workflow tehát minden egyes lépésben saját típusú taskokat dobál, s az ezekhez tartozó content type-ok határozzák meg az alkalmazandó ASPX formot. Ezeket a task content type-okat és az ASPX formokat egyaránt feature-ként szállítjuk, mint a workflow-t, és egyéb komponenseket is. Ezeket a feature-öket pedig egy solution-be csomagoljuk, s úgy adjuk át az ügyfélnek.

A fejlesztés szépen haladt, skeleton kész, a workflow elindult, a folyamat végigfutott. Egyszer azonban az egyik content type GUID-ját meg kellett változtatni, mindenféle összetett okok miatt. Feature, solution kész. Tesztrendszeren régi solution leszed, új felrak - workflow nem megy. Elindul ugyan, de az első task dobásakor leáll - keresi a task formot a régi GUID-dal. Próbáljuk újra: solution leszed, feature inaktivál, task listáról a hozzárendelt content type-okat ugyancsak leszedtük. Solution újra fel, feature aktivál, content type-okat vissza az adott task listához. A történet ugyanaz: workflow elindul, de az első tasknál meghal.

Valahol beragadt a régi GUID. De hol? Minden tartalmat letöröltünk az adott site-ról (még szerencse, hogy csak tesztadatokkal ment…). Még a Recycle Bin-t is kipucoltuk, mindkét szinten. A keresőmotorral egy újabb full indexelést elvégeztettünk. Látszólag már sehol semmi nem maradhatott, ami foghatta a régi tartalomtípust, vagyis a régi GUID-ot.

De mégis. 

Rendben, csatát nyert a MOSS, megadjuk magunkat: állítsuk vissza a régi GUID-ot. Kód átír, fordít, solution generál, tesztszerverre felmásol, régi leszed, új felrak… Mennie kell! - Hát nem! Most, hogy visszakapta a régi GUID-ot: az újat keresi. Tipikus ördögi kör, most már semmi nem jó neki, sem a régi, sem az új, úgy tűnik, a workflow-t temethetjük az örök processmezőkre.

Ekkor már hajnal 4 után jártunk. Néhány (1-2) óra alvás után ment a levél az ügyfélnek, hogy aznap ne nagyon akarjanak tesztelni, mert hát nincs mit. Mi pedig folytattuk a nyomozást, s szerencsénkre jött az “isteni” szikra, a segítség a Microsoft DPE-től: Mi az, amit nem pucoltunk ki? Bizony a file-rendszer! A formok a LAYOUTS könyvtárban, a feature-ök a FEATURES-ben. Mint Pétertől megtudtuk, a háttérben ezek verziózva, historikusan vannak tárolva! Így amikor egy taskhoz próbálunk nyúlni, megtalálja a régi GUID-okat is az historyban, a feature-ök, vagyis az aktív tartalomtípusok között viszont már nem. Ez magyarázat arra is, miért kereste az új GUID-ot, miután visszaállítottuk a régit: addigra már az is bent volt a history-ban…

A végső megoldás tehát: minden lista kipucolása, workflow leszedése a listáról, tartalomtípusok leszedése a task listáról, feature-ök deaktiválása, majd uninstallja, solution leszedése, file rendszer kipucolása a szerveren. Amikor már semmi nyoma nincs annak, hogy valaha is itt jártunk - na akkor nem fogjuk menekülőre a dolgot, hanem lehet újra hozzáadni és deployolni a solution-t, feature-öket aktiválni, a megfelelő listákhoz hozzárendelni a tartalomtípusokat és workflow-t. És a végén persze tesztelni, tesztelni, tesztelni…

És láss csodát: működik! Svájcibicska vissza a tokjába, de nem szabad túl mélyre eltenni, mert hamarosan újra szükségünk lesz rá…

Ma tették közzé az Office Developer Interactive Map 2 sz. verzióját. Az újdonságok:

• több mint 200 frissített MSDN, blog, cikk, stb. link
• bekerült a Visual Studio 2008, a PerformancePoint Server 2007
• új OBA linkek is kerültek  a felső menübe
• stb.

A tartalomtípusok (content tpye) kérdése egy élmény az életemben, csaknem minden projektünk kapcsán kihasználhatjuk a WSS 3.0 ezen új lehetőségét. Nagyon szép, elegáns ez a megoldás, mellyek dokumentumsablonokat, workflow-kat, oszlopokat, stb. állíthatunk be, egységbe zárva. Ezeket a tartalomtípusokat azután listákhoz, dokumentumtárakhoz rendelhetjük. Az alábbi ábra azt mutatja, hogy ezután hogyan módosul például a dokumentumtár New menüje:

Néhány napja Ton Stegeman publikált egy cikket “Set content type at the folder level in SharePoint” címmel. Hogyan?! Nemcsak listákhoz/tárakhoz rendelhetünk tartalomtípust?!

De. Igen is, meg nem is. Először is lássuk, amit a cikk bemutat: a dokumentumtárhoz hozzárendeljük az összes szükséges tartalomtípust, a fenti ábtán például a Document mellé felvesszük a Spec_ContentType-ot és a Spec2-t is. Hozzunk létre egy új mappát, “CsakSpecDok” néven, s kövessük a cikk utasításait: klikkeljünk a mappa kontext menüjének legalsó, “Change New Button Order” menüpontjára, s állítsuk be, hogy csak a Spec_ContentType, és a Spec2 legyen elérhető az adott mappa New menüjéből:

Valóban, az adott mappa New menüjéből ezek után hiányozni fog a Document…

De vajon ez tényleg teljes megoldás számunkra? Ha elkezdünk játszani kicsit a dokumentumtárral, a mappákkal és a tartalomtípusokkal, gyorsan észrevehetjük a trükköt: a New menüből valóban eltűnt a Document tartalomtípus, de feltöltésnél (Upload), és elem szerkesztésénél továbbra is kiválaszthatjuk, bármely mappáról legyen is szó:

A cikkben leírt megoldás tehát megoldás is, meg nem is. Nyilvánvalóan lehetnek olyan körülmények, amikor hasznos a fentiek tudása, ám véleményem szerint sok esetben inkább zavaró, megtévesztő lehet a felhasználók számára.

Vagy le kell tiltani az Upload funkciót… Vagy el kell tüntetni az EditForm.aspx-ről a Content Type field-et…

Megjelent a VSeWSS 1.1 verziója. Az újdonságok röviden:

• “WSP View”, aka “Solution Package editing”
  • No more hidden, non-editable solution content!
  • Create new Features
  • Reorder Elements between Features
  • Conflict validation against existing Features
  • Rename existing Features
  • Change Feature activation order
• Visual Basic support!
• New Item Templates:
  • “List Instance” project item
  • “List Event Handler” project item
  • “SharePoint Template” item template, e.g. “layouts” files
• Faster F5 speed (The tool no longer performs an IISReset. Now it only recycles the app pool.)
• Solution Generator: you can now choose which lists should be included when exporting a site.
• Many bug fixes, e.g.
  • No more GUIDs in Feature Names
  • Support complex project names, e.g. with periods.
  • Can deploy assemblies to the bin folder, instead of GAC

És egy újabb jó hír: a VSeWSS 1.2, melynek megjelenése júniusra várható, már a Visual Studio 2008-at is támogatni fogja!

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