ÁghyBlog

Képzeljünk el egy vállalatot, az egyszerűség kedvéért kis céget. A cégvezetés WSS 3.0 Document Library-ben kívánja tárolni a különféle szerződéseit, hogy kihasználhassa annak előnyeit. Nagyon fontos, hogy csaknem minden szerződésen többen is dolgoznak, mire az az ügyfélhez kerül (csoportmunka!), s elképzelhető, hogy maga az ügyfél is többször visszadobja, megiteráltatja azt, mire aláírásra kerülhet. A csoportmunka-támogatáson kívül a WSS 3.0 egyik nagy újítása, a tartalomtípusok kezelése teszi lehetővé, hogy teljes mértékben a cég igényeire szabjuk a dokumentumtárat.

De mik is ezek a tartalomtípusok? Minden dokumentumtárnak van egy alapértelmezett sablonja, amely alapján létrehozza az új dokumentumot, amikor a felhasználó ezt szeretné. Korábban minden dokumentumtárhoz egyetlen ilyen template-et állíthattunk be, s ez igencsak korlátozta a használatot. Gondoljunk csak bele: szerződések esetén egészen biztosan több sablonunk van. Ezeket nem használhatjuk SharePoint alatt? Vagy valamennyi sablonra külön dokumentumtárat kell létrehozni? Vajon hatékony-e külön tárolni ezeket? Utólag tudni fogom-e, hogy kivel milyen típusú szerződést kötöttem, s azt hol találom? Persze, a kereső funkció sokat segíthet…
Igen, másik opció, hogy egy dokumentumtárat használunk, de ekkor nem lehetett több sablonunk. Ez sem sokkal jobb megoldás…

WSS 3.0 alatt azonban nem kell beleharapnunk egyik kezünkbe sem: a tartalomtípusok (content type) segítenek nekünk.
A tartalomtípus gyakorlatilag egy-egy listaelemet (list item), dokumentumot (document) vagy mappát (folder) definiál. Segítségével ezek tulajdonságai (properties), a hozzájuk rendelt munkafolyamatok (workflow) és dokumentumsablonok határozhatók meg. Például definiálhatunk az egyes szerződéstípusokra egy-egy önálló, az egyszerű dokumentumból származó tartalomtípust: alvállalkozói szerződés, teljesítési igazolás, munkavállalói szerződés, bérleti, szolgáltatói szerződés, stb.

Amikor készen vannak a tartalomtípusaink, meghatároztuk tulajdonságait, létrehoztuk s hozzárendeltük a megfelelő sablonokat és munkafolyamatokat – nos ebben a pillanatban már hozzá is rendelhetjük az egyes listákhoz és dokumentumtárakhoz. Ezáltal azt definiáljuk, hogy az adott lista vagy dokumentumtár milyen típusú elemeket tartalmaz, s új elem/dokumentum létrehozásakor már nem csupán a „New Item” vagy „New Document” opciók közül választhatunk, hanem a definiált és hozzárendelt content type-ok mindegyikéből. Vagyis így ugyanazon dokumentumtáron belül is egyetlen kattintás dönti el, hogy melyik szerződéstípust hozzuk létre!

A WSS 3.0 listákban és dokumentumtárakban természetesen a különböző tartalomtípusok oszlopainak kezelése is megoldott. Amennyiben az egyes típusok különböző oszlopokat tartalmaznak, az egyes listákhoz/dokumentumtárakhoz a WSS a tartalomtípusok oszlopainak unióját rendeli. Természetesen ezeken felül is definiálhatunk még, az adott listához/dokumentumtárhoz tartozó oszlopot. Szerződések esetén például tegyük fel, hogy az alvállalkozói szerződéshez az alábbi oszlopokat definiáltuk:

• sorszám
• partner cég
• kapcsolattartó személy
• szerződés hatálya – kezdő dátum
• szerződés vége – lejárat

Ugyanezen dokumentumtárhoz rendeljük a munkavállalói szerződéseket is, melyek paraméterei:

• sorszám
• alkalmazott
• születési hely
• születési idő
• lakcím
• szerződés hatálya – kezdő dátum
• szerződés vége – lejárat

Az oszlopok uniójának képzése után a dokumentumtár automatikusan létrehozott oszlopai tehát:

• sorszám
• partner cég
• kapcsolattartó személy
• alkalmazott
• születési hely
• születési idő
• lakcím
• szerződés hatálya – kezdő dátum
• szerződés vége – lejárat

Tervezési kérdés, hogy az azonos típusú(nak tűnő) oszlopokat összevonhatjuk-e (pl. kapcsolattartó személy – alkalmazott), vagy szükség van ezek megkülönböztetésére.

Érdemes még megemlíteni, hogy a content type-okat site szinten definiáljuk, s elérhetőségük kiterjed az adott site, és annak valamennyi leszármazott site-jának valamennyi listájára és dokumentumtárára. Ajánlott tehát alaposan végiggondolni, hol milyen tartalomtípust definiálunk, hiszen az elérhetőség sok mindent befolyásolhat.

S akkor a webhelyoszlopokról (site column) még nem is írtam…

SharePoint terminológiában „library” a tisztességes neve azoknak a táraknak, ahol különféle file-okat tárolunk, és osztunk meg más felhasználókkal. A Dokumentumtár (Document Library) alkalmas arra, hogy általános dokumentumkezelési (s nem iratkezelési! – erről majd később) funkciókat ellásson: tárolás, közös szerkesztés megvalósítása, megosztás, verziókezelés, stb. A Windows SharePoint Services 3.0 alatt már arra is lehetőségünk van, hogy egy-egy dokumentumtárba több tartalomtípust (content type) is létrehozzunk, sőt különféle munkafolyamatokat (workflow) is „húzhatunk” a library elemeire.

Mindezen funkciók közül különleges figyelmet érdemel a verziókezelés (versioning) megvalósítása. A dokumentumok készítése, szerkesztése során úgynevezett verziókat (version) hozunk létre, melyek mentén végigkövethetjük annak életciklusát, szerkesztési menetét. Az egyes verziókat növekvő számozással jelöljük. A WSS 3.0-ban háromféle verziózási módot különböztetünk meg:

• None: Nincs verziókezelés, azaz a dokumentumok korábbi változatait nem tároljuk, azok nem elérhetők. Ennek megfelelően a history-t sem tudjuk végigkövetni. Akkor használjuk ezt az opciót, ha nem fontos a korábbi változatok elérése, vagy ha olyan dokumentumokat kívánunk tárolni, melyek már nem változnak.
• Major versions only (csak főverziók): Az egyes verziókat pozitív egészek jelölik (1, 2, 3, …). Akkor használjuk ezt az opciót, ha nem kívánunk különbséget tenni a dokumentumok munkapéldányai és a publikálható változatai között, hanem egységesen akarjuk kezelni őket. Amikor elmentjük a dokumentumot, minden alkalommal új, eggyel magasabb számozású verzió jön létre, melyhez minden felhasználó a saját jogosultságai szerint fér hozzá.
  Ha kézben szeretnénk tartani a dokumentumtár méretnövekedésével járó problémákat, beállíthatjuk, hogy az utolsó verziók közül hányat kívánunk eltárolni, s a többiek törlésre kerülnek. Például ha az 5. verziónál járunk, s beállításaink szerint 3 változatot őrzünk, a 4. és 3. verzió még hozzáférhető lesz, a 2. és 1. azonban már nem.
• Major and minor versions (fő- és alverziók): Az egyes verziókat pozitív egészekből és tizedesjegyekből álló számok jelölik (1.0, 1.1, 1.2, 2.0, 2.1, …). Akkor használjuk ezt a verziókezelési sémát, ha meg akarjuk különböztetni a publikálásra kerülő, megfelelő jogosultsággal rendelkezők számára hozzáférhető változatokat a publikálásra még nem „érett” munkaverzióktól (draft). A .0-ra végződő verziószámok jelölik a publikus főverziót, a nem .0-ra végződők pedig az alverziókat. A főverziók mindenki számára eléhetők, akik legalább olvasási joggal rendelkeznek a dokumentumtárhoz – ezzel szemben az alverziókhoz külön kell definiálni, hogy kik férhetnek hozzá (tipikusan azok, akik az adott dokumentum szerkesztésében részt vesznek).
  Ha kézben szeretnénk tartani a dokumentumtár méretnövekedésével járó problémákat, beállíthatjuk, hogy az utolsó főverziók közül hányat kívánunk eltárolni; illetve azt is, hogy hány főverzióhoz akarjuk megtartani az alverziókat is.

Szorosan a verziókezeléshez kapcsolódik a tartalom-jóváhagyás (content approval) folyamata is. A dokumentumnak az a munkaverziója, amely még nem került jóváhagyásra a megfelelő szerepkörrel (Approval) rendelkező jóváhagyó személy(ek) által, függő (Pending) állapotban van, s csak a sikeres jóváhagyás után válik mások számára is elérhetővé. Hogy maga a jóváhagyás hogyan történik pontosan, az függ a dokumentumtár verziókezelési beállításaitól is:

• None: Amennyiben nincs verziókezelés, a dokumentum mentése esetén annak státusza függő (Pending) lesz. A WSS az előző, jóváhagyott verziót továbbra is publikusan elérhetőként tárolja egészen az új verzió jóváhagyásáig. Ekkor ugyanis mintegy felülcsapja a régit az újjal, s ez lesz az egyetlen elérhető változat. Hasonlóan, dokumentum feltölésekor vagy új dokumentum létrehozásakor annak státusza azonnal függő lesz, s publikusan mindaddig nem érhető el a felhasználók számára, amíg a jóváhagyás sikeresen le nem futott.
• Major versions only: Ha csak főverziókat számozunk, a dokumentum mentése esetén annak státusza függő (Pending) lesz, a korábbi verziók pedig változatlanul elérhetők. Az új verzió jóváhagyásakor annak új, inkrementált verziószámot ad a WSS, publikusan elérhetővé teszi a felhasználók számára, a korábbi verziókat pedig a beállításoknak megfelelően az úgynevezett version history-ban őrzi.
• Major and minor versions: Fő- és alverziók számozása esetén dokumentum mentésekor választhatunk: új főverziót szeretnénk-e létrehozni, vagy az adott főverzión belül egy alverziót. Ez utóbbi esetben létrejön a megnövelt számozású alverzió, mely továbbra is csak a szerkesztők számára elérhető. Főverzió mentése esetén a dokumentum státusza függő (Pending) lesz, s az egészen a jóváhagyásig nem érhető el publikusan. Ekkor kap egy inkrementálisan megnövel főverziószámot, elérhetővé válik, a korábbi változatok pedig bekerülnek a history-ba.
  Új verzió feltöltésekor vagy létrehozásakor menthetjük munkaváltozatként (Draft) 0.1 verziószámmal, vagy kérhetjük azonnali jóváhagyását.

Mindezen opciók segítségével, a megfelelő beállítások alkalmazásával igen széleskörű igények kiszolgálására is alkalmassá vált a WSS 3.0. Érdemes kipróbálni!

Szokásos felállás: Megrendelő, Fővállalkozó, Alvállalkozó. Tipikus projekt-felállás, nem? A pénteki Architektúra Fórumon hangzott el a kérdés: a követelményspecifikáció vajon cél, vagy eszköz?
Cél, ha mérföldkőként tekintünk rá: el kell érni ahhoz, hogy az ügyféltől az első adag pénzt megkapjuk.
Eszköz, ha azt látjuk benne, hogy később, a projekt megvalósítása során mekkora szükségünk lesz rá.

De vajon mi történik akkor, ha nincsenek előre rögzítve a követelmények?
A Megrendelő tudja, mit szeretne. A Fővállalkozónak van egy elképzelése a megvalósítás hogyanjáról. Az Alvállalkozó pedig legjobb tudomása szerint igyekszik teljesíteni, amit elvárnak tőle. De követelményspecifikáció híján ő maga sem tudja, mi ez. S ahogy ez tudatosul benne, úgy indul a lavina… Mert persze mindez újabb és újabb problémák kapcsán lesz egyre világosabb.
A Fővállalkozó által biztosított technikai háttérrel gondok vannak, az Alvállalkozó nem tudja rendesen végezni a dolgát. - Ez vajon kinek a hibája? Nyilván az Alvállalkozó az, akire a legkönnyebb rákenni: nem tudta áthidalni ezeket a problémákat. A Fővállalkozó mossa kezeit.
A Megrendelő is elégedetlen: nem azt, és nem olyan minőségben kapja, ahogyan szeretné. Ki a hibás? Nyilván ismét az Alvállakozó, aki a fent említett technikai nehézségek miatt belebukik a demóba. Az természetesen nem érdekli a Megrendelőt, hogy miért. A Fővállalkozónak pedig csak jól jön, hogy az ő neve fel sem merül a felelősségrevonás során.

Mi marad az Alvállalkozónak? Semmi. Egy elégedetlen Megrendelő, aki kommunikálni csak a Fővállalkozóval hajlandó - és egy Fővállalkozó, akinek nyilván az az érdeke, hogy a Megrendelő vele kávézzon jövő héten is.

Ez lesz a követelményspecifikáció hiányából… S most vajon a cél vagy az eszköz nem volt megfelelő?

A SharePoint Server egyik központi funkciója a keresés - viszont ez is, mint annyi minden, csak akkor áll kézre, csak akkor felel meg az igényeinknek, ha megfelelően testreszabjuk, magunkhoz, elvárásainkhoz igazítjuk.

A beállítások első szintje a Shared Services Provider (SSP) - itt definiálhatunk tartalomforrásokat (content source), és úgynevezett scope-okat is.
A content source azt definiálja, hogy MOSS szerverünk honnan indexelje be a tartalmat. Különféle forrástípusokat adhatunk meg:

• SharePoint site
• Web site (bárhol a világon, nem szükséges a saját intranetünkön lennie)
• File Share (file-rendszerbeli elérés)
• Exchange Public Folder
• Business Data (BDC-ben definiált adatforrások)

Példaként lássuk, hogyan lehet SharePoint alatt beindexelni, és használni egy weboldalat - például a http://aghy.hu -t
Adunk tehát egy nevet az adatforrásnak (ÁghyBlog), Web site típusúnak állítjuk be, s megadjuk az URL-t. A Crawl settings blokkban azt adhatjuk meg, milyen mélységben szeretnénk keresni az adott oldalon. Végül az ütemezést defniálhatjuk: milyen gyakorisággal történjen teljes, s mikor inkrementális indexelés.
Új forrás létrehozásakor érdemes kezdeményezni egy azonnali, teljes indexelést - természetesen csak akkor, ha az ezáltal jelentkező terhelés összhangban áll a meghatározott üzleti érdekkel. Ha elegendő például másnaptól használni az adott forrást, hagyatkozhatunk az éjszakára beállított, ütemezett indexelésre is.

Következő lépés tehát a scope definiálása. Egy-egy scope több feltétel alapján is összeállhat, és ezeknek a feltételeknek nem is szükséges azonos típusúnak lennie. Így van lehetőségünk például arra, hogy a People Search scope-ot kiterjesszük, s ne csak az autentikált SharePoint felhasználókat jelenítse meg a találati listában, hanem valamely Contact lista elemeit is - természetesen akár több unióját is.
Definiálunk tehát egy scope-ot, amely egyetlen szabállyal rendelkezik: az AghyBlog content soure elemeire keres.

Természetesen további rule-ok hozzáadására is hasonló módon van lehetőségünk, például ide rendelhetjük az adott SharePoint site-on lévő azon tartalmakat, melyek szerzője az Aghy nevű felhasználó (Property Query).

Kész tehát a tartalomforrás, kész a scope, már csupán “aktiválnunk” kell azt. A scope-ok frissítése ütemezetten történik (Next scheduled update), de manuálisan is eszközölhetjük azt (Start update now).

Kész az SSP, irány a site collection!
Az adminisztrációs felületen, a Search scopes menüpont kiválasztásával “hozhatjuk elő” a használni kívánt, de még “unused scope”-okat, ezáltal emeljük be a kereséseink, s a Search box lehetőségei közé:

És íme, láss csodát: az új scope működik! A “SharePoint” szóra rákeresve itt az eredmény (klikk a képre!):

És ez csak a kezdet…

Fejlesztői környezetet kellett összeraknom MOSS 2007-hez. Ami a gépre került:

• alap-infrastruktúra: Win2003 (Domain Controller is egyben), SQL2005, MOSS2007
• ASP.NET 2.0 (IIS-ben is engedélyezni kell!)
• .NET framework 3.0 (a Windows Workflow Foundation miatt)
• Visual Studio 2005
• SharePoint Server 2007 SDK
• Visual Studio 2005 Extensions for Windows SharePoint Services
• Visual Studio 2005 Extensions for Windows Workflow Foundation

Márciusban linkeltem ide egy cikket a SharePoint 2007 telepítéséről, most egy speciális aspektusát írnám körül, hiszen a tanfolyamokon ez újra és újra visszatérő kérdés. Mégpedig a farm és a stand-alone telepítés.

Kezdjük az “egyszerűbb” esettel: stand-alone. Ha ezt az opciót választjuk, abban a meglepetésben lesz részünk, hogy a telepítő gyakorlatilag semmit nem kérdez, hanem egyszerűen felkúszik a MOSS, és kész. Nincs adatbázisszerver-érdeklődés, semmi. Megy és kész. De hol vannak ekkor az adatok? Mi is történik pontosan?
Nos, a MOSS úgy értelmezi, hogy ha stand-alone, akkor minden az ő feladata, s ezt szépen le is zongorázza: felpakol egy SQL Server 2005 Express-t, beállítja a szükséges config és content adatbázisokat, stb. Működik, fejlesztői környezetnek jó lehet, éles rendszer esetén azonban számolnunk kell az SQL Express korlátaival…

Ahhoz, hogy saját, meglévő SQL 2005 szerverünket konfigurálhassuk be a SharePoint 2007 alá, bizony farmot kell telepítenünk. Első ránézésre furcsa lehet, ha fizikailag egy gépen van minden (DC, SQL, MOSS), de próbáljunk logikailag, a SharePoint fejével gondolkozni (micsoda képzavar! ) - az ő szempontjából az SQL server egy “kívülálló”. Akkor is, ha ugyanazon a vason ülnek. Ugyanígy “kívülálló” a domain controller, az SMTP, stb. is. Lényegtelen, hogy fizikailag hol vannak. Nem számít.
Logikailag más szerver, és kész.
Ezért kell a farm telepítést választanunk. Ekkor van lehetőségünk annak konfigurálására, hogy hol lesz az adatbázis, milyen SMTP szervert fogunk használni, stb. Akkor is, ha ezek elérése (IP cím) megegyezik a MOSS-éval.

Természetesen ez utóbbi esetben van lehetőségünk a későbbiekben arra is, hogy az egyes funkciókat átpakoljuk más szerver(ek)re (vagy már alaphelyzetben is így állítsuk be), így a farm tényleg farm lehet…

“Mi az a mester? Hát megmondom én: nem az a mester, aki megtanít valamire, hanem aki megihleti a tanítványt, hogy legjobb tudását latba vetve fölfedezze azt, amit már addig is tudott.”

(Paulo Coelho)

SPS2003-hoz volt fejlesztői tanfolyam, 2014: Customizing Microsoft SharePoint Products and Technologies 2003 néven. MOSS-hoz (még) nincs, igény viszont van rá, ezért épp saját tematikát és laborkörnyezetet rakok össze. Majd beszámolok, és írok erről bővebben is, ha lesz egy kis szusszanásnyi időm.

Közben persze megy az 5060 (Implementing Microsoft Windows SharePoint Services 3.0) és az 5061 (Implementing Microsoft Office SharePoint Server 2007), illetve ezek testreszabott verziói is.

Izgamas…