ÁghyBlog

Web Content Management Links and Resources

A gyűjtemény kb. egy éve nem frissült, de érdemes lehet átnézni.

Grafikonkészítés SharePoint (WSS 3.0 vagy MOSS 2007) alatt? Egy nagyon meggyőző megoldást találtam: Dundas Chart for SharePoint. A legfontosabb adatforrások, melyekből táplálkozni tud: Business Data Catalog, Excel Services, Web Parts, OleDB Data Sources.

A képre kattintva tekintheted meg a demo videót:

Új SharePoint site létrehozásakor (egyéb adatok megadása mellett) szükség van egy template (sablon) kiválasztására is, amely alapján létrejön a kezdeti struktúra. Ez a site template (webhelysablon) határozza meg a site-hoz tartozó alapértelmezett oldalakat (pages), listákat, tárakat (libraries), valamint egyéb elemeket és feature-öket. Ezek fogják meghatározni a site viselkedését: a publikálási, tartalom- és iratkezelési, valamint üzleti intelligenciával kapcsolatos lehetőségeinket.

MOSS 2007 alatt az elérhető site template-ek a következők:

(more…)

Ha SharePoint 2007 alatt Site Directory-t hozunk létre, mondjuk a http://mymoss címen, érdekes dolgot láthatunk. A felület jobb felső sarkában, a gyorslinkek között található “Create Site” ugyanis nem működik!

 Ahova mutat: http://_layout/newsbweb.aspx. Nyilván a helyes link a http://mymoss/_layout/newsbweb.aspx lenne…

Bátorfi Zsolt blogjában találtam rá erre a projektre:

“The LINQ to SharePoint project provides a custom query provider for LINQ that allows to query SharePoint lists using familiar LINQ syntax. LINQ stands for Language Integrated Query and is one of the core features of Microsoft’s .NET Framework 3.5 release.“

Végre!

MSF? RUP? Saját módszertan? De milyen? Hogyan válasszuk ki, mi “passzol” az adott ügyfélhez? Mi történik/történhet, ha rosszul döntünk?

Két fontos tényező a siker kulcsa: a kiválasztott módszertan kellő ismerete, valamint az ügyfél ismerete. A kettőt a testreszabás köti össze: a kiválasztott módszertan kialakítása az adott ügyfél igényeinek megfelelően.
Az, hogy az ügyfelet mennyire ismerjük, sok tényezőtől függhet. Mióta állunk vele kapcsolatban, mennyire “aktív” ez a kapcsolat? Mi magunk mennyire tudunk egy-egy ember vagy cég “rezdüléseire” odafigyelni, mennyire értjük őt, mennyire olvasunk akár a gondolataiban is? Ő mennyire ismer bennünket?
A módszertan ismerete és testreszabási képessége gyakorlatilag szakmai feladat, mégis számos emberi tényező is befolyásolja. Néha maga az ügyfél is…

Elmesélek egy példát.
Az ügyfél egy viszonylag kis cég, néhány saját fejlesztővel, de szeretne megvalósítani egy központi rendszert, melyet külső emberre bízna. A külsős ember specifikál, heti két napot biztosít az ügyfél számára (tehát nem ül be állandóra az irodába, ez fontos tényező!), s ez jónak is tűnik. Az ügyfél örül, lelkes, túlteng benne a tettvágy.
“Ügyfél” alatt természetesen a megbízó céget értem, de nyilvánvalóan van képviselőjük, aki a külső vállalkozóval egyeztet. Rajta kívül dolgoznak még mások is a cégben, akik értelemszerűen végzik a munkájukat. És itt jön a svédcsavar: az egyik dolgozó elégedetlenkedik teázás/kávézás közben, vagy csak úgy az asztalánál ülve, hogy X dolog még nincs készen.
Az egyik belső fejlesztő ezt meghallja, s egy másik technológiával pikk-pakk megoldja. Kicsit más a megoldás, mint ahogyan a külső fejlesztő eltervezte: nemcsak technológiában, hanem logikailag is. Sebaj, a problémafelvető boldog, a nyomtatóból árad a papír - csak épp ezzel az egész eltervezett koncepció felborult.

Ki a hibás? A külső fejlesztő, aki nem ül bent napi 8-10 órában az ügyfélnél? Az ügyfél képviselője? A belső fejlesztő? Az elégedetlenkedő dolgozó? Miért került a fejlesztés két szék közül a vizesárokba?

Valahol elcsúszott a dolog. Az ügyfél nem tudott szakítani rég bevált szokásaival. Elkényelmesedett: az irodában ülő fejlesztőt a nap bármely pillanatában lehet zargatni, ezt csináld, azt csináld… Hogy ebből mi lesz készen, persze más kérdés.
A külső fejlesztő pedig nem ismerte fel, hogy a hangzatos lelkesedés mögött ott lapul ez a kényelmes monotonitás, melyből talán a legnehezebb kirángatni az ügyfelet.

Az ügyfél gyakran a megváltót látja a beszállítóban. S valamilyen szinten persze az is, hiszen feladata az ügyfél problémáinak megoldása, de ehhez aktívan(!) szükség van az ügyfélre is. Segíts magadon, az Isten a beszállító is megsegít…

A MOSS2007 egyik nagy, új komponense a Business Data Catalog (BDC) készítésének lehetősége. Ennek segítségével van lehetőségünk arra, hogy külső alkalmazásokból, adatforrásokból (pl. SAP, Oracle adatbázisok, stb.) emeljünk be adatokat SharePoint felületünkre. A hangsúly elsősorban az adatmegjelenítésen van, de van lehetőségünk azokat módosítani is - erről majd később.

Egy vállalatirányítási folyamatban például óriási jelentőségű lehet, ha egy felületen tudjuk megjeleníteni a különféle kimutatásokat, statisztikákat, lekérdezések eredményeit, ügyféladatokat, stb. - s nem kell ehhez több különböző rendszert megnyitnunk, paramétereznünk. A MOSS előre elkészített webkijelzőkkel támogatja az adatmegjelenítés ezen új módját: (teljes vagy szűrt) elemlistát is kérhetünk és egyes elemeket külön-külön is megnézhetünk, sőt SharePoint-elemekhez is rendelhetünk új BDC oszlopokat. A lehetőségek tehát csaknem korlátlanok - természetesen saját megjelenítő formokat is definiálhatunk. Sőt, a BDC oszlopoknak köszönhetően olyan listáink is lehetnek, melyek az adatok egy részét SharePoint-ból, másik részét egy LOB adatbázisból veszik…

És hogy hogyan lehetséges mindez? Egy XML leíró file-ban (metadata file) adhatjuk meg az elérendő adatforrás (adatbázis vagy webservice) paramétereit, s ennek segítségével a megfelelő Shared Service admin-felületén importálhatjuk be a definíciót. Ha megfelelően konfiguráltuk a rendszerünket, ezután már hozzá is férhetünk a háttér-adatokhoz - értelemszerűen a megfelelő jogosultságokkal.

A módosítás, adatbázisba történő visszaírás kissé összetettebb dolog. Ehhez úgynevezett Action-t kell definiálni a BDC-hez, amelyet felületről hívhatunk meg az elemekhez. Ez az Action egy paraméterezhető url formájában testesül meg - ami tehát lehet az eredeti alkalmazás egy webes oldala (ahol a módosításokat eszközölhetjük), vagy saját .aspx lap is, ahol magunk valósítjuk meg a háttér-rendszerrel történő kommunikációt.

Ha pedig még egyet akarunk csavarni a dolgon, az is elképzelhető, hogy igényeinknek egy komplex Workflow felel meg, amely nemcsak a megfelelő jóváhagyási (vagy egyéb) lépéseket tartalmazza, hanem a megfelelő módosításokat is lekezeli…

Szép, nem?

Ha az ember lányát már alig-alig locsolja meg valaki, Beni pedig épp a Nagyszülőkkel kirándult Dédiékhez, húsvét hétfő ide vagy oda, én bizony dolgoztam. Hiába, az induló cégek már csak ilyenek…

Szóval most éppen SharePoint Workflow-kat készítgetek, ismerkedem mélyebben is ezzel a lehetőséggel. De hogy ne rögtön a mélyvízbe ugorjunk, lássuk az alapokat. Hogyan is működik mindez?
A MOSS alapvetően a .NET framework 2.0-ra épít, annak funkcionalitását használja (a háttérben .aspx lapok ketyegnek). De. A Windows Workflow Foundation a .NET fw. 3.0 része, így erre a verzióra is szükség van ahhoz, hogy munkafolyamatainkat SharePoint Server 2007-tel támogathassuk.

SharePoint-terminológiában a workflow-t (munkafolyamatot) egy adott listaelemen vagy dokumentumon meghatározott szabály(ok) szerint végrehajtandó feladatok összességeként határozhatjuk meg. Minden folyamatot egy sablon (template) definiál.

A háttér-infrastruktúrát többféleképpen is kihasználhatjuk, nyilván attól függően, hogy mire van szükségünk. A SharePoint Server 2007 Standard, illetve Enterprise és “for Internet” verziókban találunk “gyári”, pre-defined, úgynevezett out-of-the-box workflow-kat, amelyeket a telepítést követően, minimális beállítások után azonnal használhatunk is:

• Approval: jóváhagyási folyamatot indít a dokumentumra/listaelemre. A workflow indítója meghatározhatja a jóváhagyók személyét, akiknek lehetősége lesz elfogadni vagy visszautasítani a dokumentumot, átruházni a jóváhagyást, vagy a dokumentumon változásokat kezdeményezni.
• Collect Feedback: a jóváhagyáshoz hasonló folyamat, amely a dokumentot áttekintésre továbbítja az illetékeseknek. Ők megjegyzéseket, visszajelzéseket fűzhetnek az elemhez melyeket természetesen a dokumentum szerzője megkap. A jóváhagyási folyamattal ellentétben (mely alapértelmezésben sorosan, egymás után adja a dokumentumot az illetékeseknek), ez a workflow párhuzamosan indítja az egyes feladatokat (task), így a visszajelzések tetszőleges sorrendben érkezhetnek.
• Collect Signatures: aláírásgyűjtési folyamatot indít az adott Office dokumentumra. Ez a munkafolyamat csak az adott Office kliensből indítható.
• Disposition Approvals: ez a munkafolyamat a dokumentumok megtartásának kezelését segíti azzal, hogy a résztvevőknek lehetőségük van eldönteni: a lejárt dokumentumokat törölje vagy tartsa meg a rendszer.
  (Forrás: MSDN: Workflow and Office SharePoint Server 2007)

Természetesen saját WF definiálására a többi Server verzióban, és a WSS 3.0-ban (Windows SharePoint Services) is van lehetőség.

A folyamat-definíció első lépcsője a SharePoint Designer. Ez az eszköz lehetőséget biztosít számunkra, hogy előre definiált tevékenységeket (activity, action) egy adott listához kapcsolódó munkafolyamattá fűzzünk össze. Gyakorlatilag “összeklikkelgetjük” a WF-t - természetesen az ennek megfelelő korlátokkal együtt:

• SharePoint Designerrel csak szekvenciális WF-k összeállítására van lehetőségünk, úgynevezett “state machine”-t nem építhetünk.
• Csak a meglévő, Designer által ismert tevékenységekkel dolgozhatunk.
• A munkafolyamat azonnal egy adott listához vagy dokumentumtárhoz kapcsolódik, nem kell/lehet a telepítéssel foglalkoznunk.
• A WF debuggolására nincs lehetőségünk.

Egyszóval a Designer valóban designereknek készült, akik kódolás nélkül szeretnék kihozni a lehető legtöbbet a SharePoint-ból. (Természetesen a WF-építésen kívül számos más funkciója is van, de erről majd később.)

Ha saját activity-ket szeretnénk fejleszteni, vagy más okból nem elég a Designer funkcionalitása, a Visual Studio-t használhatjuk. A Designer és a Studio munkafolyamatokat érintő összehasonlítását itt találjátok.

Egy dolgot még érdemes megemlíteni. Sajnos jelenleg a workflow-k távoli debuggolása nem igazán megoldott, azt a Visual Studio 2007-től várhatjuk majd…

Magyar nyelven az alábbi SharePointhoz kapcsolódó fórumok érhetők el (legjobb tudomásom szerint):

• devPORTAL - Microsoft Fejlesztői Portál
• Microsoft Technet szakmai fórum
• NetAcademia Tudástár

Többről nem tudok, persze ez nem zárja ki annak lehetőségét, hogy mégis van.

Íme egy összehasonlítás az egyes Sharepoint verziókról, és azok funkcionalitásáról: SharePoint Products Comparison

Kezdetben vala az ember, aki elkötelezi magát egy cég mellett, ott dolgozik, és pont. Néha állást vált, de a konstrukció ugyanaz marad.
Aztán gondol egyet, a főállás mellett bevállal ezt-azt, de biztos háttérnek még szükség van a Nagy Testvérre. Félig-meddig megvan a függetlenség érzése, de a biztonság is.

Ezek után ismét egy merész lépés: elszakadni mindenkitől. Saját vállalkozás. Valami, ami már régóta benne volt a levegőben. Most egyszeriben összeáll a kép. Jönnek a megbízások. A csillagok állása is azt súgja: most kell.

Most.

Reméljük, jól olvastuk a jeleket…