Iratkezelő rendszer fejlesztése WPF alapokon

Az előadások a következő témára: "Iratkezelő rendszer fejlesztése WPF alapokon"— Előadás másolata:

1 Iratkezelő rendszer fejlesztése WPF alapokon
Bertók Katalin Konzulens: Albert István

2 Feladat Az Iqsys vastag kliens alapú elosztott elektronikus iratkezelő rendszerének megismerése Az iratkezelő kliens iratkezelési és vezetői funkciókat tartalmazó alrendszerének implementálása WPF XBAP-ként A szolgáltatásoldallal való kommunikációhoz szükséges szolgáltatások implementálása WCF technológiával Megismerkedés az új WPF és WCF technológiával . Az elektronikus iratkezelő rendszer az iratkezelési folyamatok széles skálájának támogatása (érkeztetés, átadás-átvétel, iktatás, sztornózás, ügyintézés, kiadmányozás, postázás, lezárás, aktiválás, irattárazás) mellett lehetőséget nyújt az iratok rendezésére, tárolására, visszakeresésére, segítségével pontosan nyomon követhetjük az irat teljes életútját is, ki milyen műveleteket végzett vele, hogyan került a jelenlegi állapotába.

3 .NET 3.0 A .NET 3.0 (korábban WinFx) nem más, mint a .NET 2.0 kiegészítve az alábbi négy új technológiával: Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), és Windows CardSpace (WCS). A keretrendszer CLR-je maradt a korábbi, 2.0-s verzió, és a C# nyelv is maradt a korábbi, 2.0-s verzió, tehát a framework „csupán” szerelvénykönyvtárakkal bővült. A WPF az új keretrendszer megjelenítési rétegét nyújtja, a WCF pedig a kommunikációs rétegét

4 WPF Céljai: elérhető: Vista, Windows XP, Windows Server 2003
egységes környezetet nyújtani modern felhasználói felületek kialakításához támogatni a fejlesztők és a designerek közötti hatékony együttműködést közös technológiát teremteni vastag kliens és webes alkalmazások fejlesztéséhez elérhető: Vista, Windows XP, Windows Server 2003 számos grafikus technológiát integrál Microsoft Expression Interactive Designer tool

5 WPF 2 API: XAML, C# Element Tree: felületelemek fahierarchiába rendezettek Dependency Propertyk Új eseménykezelő modell WinForms vezérlők hosztolhatóak a vezérlők vizuális megjelenítése, funkcionalitása és adattartalma elkülönül vezérlők egymásba ágyazhatóak, végletekig testreszabhatóak, animálhatóak képek, animációk, videók, hangfájlok, két- és háromdimenziós grafikák, XPS A technológia által nyújtott lehetőségeket két API-n (programozói interface-en) keresztül is elérhetjük: a WPF alkalmazásokat írhatjuk C#, vagy más támogatott nyelven, illetve használhatjuk az új XAML nyelvet [15]. Általában utóbbit használjuk a felhasználói felület kinézetének definiálására, előbbit pedig az alkalmazáslogikát tartalmazó mögöttes kód implementálására (pl. felhasználói események kezelésérére), de akár mindent írhatunk az előbbiben is, illetve lehetőségünk van igen egyszerű alkalmazások pusztán XAML nyelvű implementációjára is A WPF a felhasználói felület fejlesztéséhez számos beépített vezérlőt nyújt (ezekről áttekintést nyújt a [7]-es forrásmű), de emellett a Windows Forms controljai is hosztolhatóak WPF alkalmazásokban a System.Windows.Forms.Integration névtér WindowsFormsHost osztályának segítségével, sőt, a WPF-es controlok is használhatóak Windows Forms alkalmazásokban ugyanezen névtér ElementHost osztályának segítségével. A WPF felületelemeinek fő építőkockáit a System.Windows névtér UIElement, FrameworkElement, ContentElement és FrameworkContentElement osztályában találjuk. A felületelemek fahierarchiát alkotnak, ez az ún. Element Tree. Kétféle Element Tree-t különböztethetünk meg, a Logical Tree-t, melyet leginkább úgy képzelhetünk el, mint a vezérlők hierarchiája azok belsőbb részei nélkül, és a Visual Tree-t, mely „finomabb felbontású” a Logical Tree-nél, tartalmazza annak minden elemét, és ezen felül minden vizuális elemet, mely a felhasználói felületet alkotja (pl. ControlTemplate-eket és DataTemplate-eket). Dependency Propertyk által lehetővé teszi, hogy egy elem automatikusan megossza a propertyeit gyermekeivel. A WPF eseménykezelése is újszerű, az események a Visual Tree-ben vándorolnak a gyökérelem és az eseményt kiváltó elem között, miközben minden útmenti elem kezelheti őket. Megkülönböztethetünk a gyökértől az adott vezérlőig lefutó „alagút eseményeket”, és az adott vezérlőtől felfelé szálló „buborék eseményeket”. A vezérlők tartalmazhatnak más vezérlőket is, pl. egy tabfülre kitehetünk akár egy buttont és egy listboxot is. A WPF technológia lehetőséget nyújt számunkra a vezérlők működésének, kinézetének és adattartalmának elkülönítésére és a végletekig történő testreszabására ( akár még animálhatjuk is azokat). WPF alkalmazásainkba egyszerűen integrálhatunk képeket, animációkat, videókat, hangfájlokat. Két- és háromdimenziós grafikákat készíthetünk egyszerűen. Az XPS (XAML Paper Specification) pedig egységes fizikai megjelenést képes biztosítani a segítségével definiált dokumentumoknak, függetlenül azok megnyitási körülményeitől.

6 XBAP kliens előnyei vastag kliensnél egyszerűbb telepítés és karbantartás nagyobb interaktivitást nyújt a vékony kliensnél a kliensoldali erőforrások kiaknázásával, egyszerűbb fejlesztés alapértelmezés: Security Sandboxban fut, de certificate-tel full trust igényelhető WPF lehetőségeinek kihasználásával jobban testreszabható design hátránya: nem platformfüggetlen (OS-re telepített WPF és XBAP-ot futtatni képes böngésző szükséges) egyszerűbb bekapcsolódást biztosít az új iratfeldolgozó egységek számára a rendszerbe, hiszen csupán intranetre és egy XBAP-ot futtatni képes böngészőre (Internet Explorer 6.0 vagy újabb verziója) van szükség a kliens gépén, valamint az operációs rendszerre telepített WPF-re (ami a Windows Vistának már része), és a felhasználó ClickOnce módon, egyetlen kattintással máris telepítheti és futtathatja a böngészőben az iratkezelő klienst, és azonnal végezheti is az ügyintézést. Az esetleges újabb termékverziók is ClickOnce módon települnek és futnak. Tehát az alkalmazás ugyanolyan egyszerűen telepíthető, mint egy vékony kliens alkalmazás, ám jelentősen könnyebben fejleszthető, és nagyobb felhasználói interaktivitást nyújt annál, hiszen nem kell az általában csekély felhasználói élményt nyújtó és lassú, kérés-válasz alapú, állapotmentes vékony kliens modell korlátaival megküzdenünk, és nem kell az interaktivitás javascripttel történő feljavításán fáradoznunk, elég egyszerűen rábíznunk az arra képes böngészőre az XBAP állományunk futtatását és ezután már csak az üzleti adatok továbbítását kell a hálózaton keresztül végeznünk. A WPF segítségével fejleszthetünk XAML Browser Application (XBAP) és standalone alkalmazásokat is, mindkét esetben használhatunk ClickOnce telepítést. Az XBAP alkalmazások WPF-fel felvértezett Windows rendszereken képesek futni a felhasználó webböngészőjében, jelenleg az Internet Explorer 6-os és 7-es verziója alkalmas erre. A ClickOnce technológia segítségével az alkalmazás mindössze egyetlen kattintással letöltődik, települ és fut a gépünkön, mintha csak egy weboldalt nyitottunk volna meg. Kommunikálhat a szerveroldallal a HTTP és SOAP protokoll segítségével, így alkalmas elosztott alkalmazások frontendjének. Az XBAP alkalmazások a böngésző security sandboxában futnak, tehát alapértelmezésben nincs teljes hozzáférésük annak erőforrásaihoz, így védve a felhasználót a rosszindulatú alkalmazásoktól. Ezáltal számos megkötés vonatkozik rájuk, például nem használhatnak Windows Forms vezérlőket, önálló ablakokat, nem jeleníthetnek meg sem saját dialógusablakokat, sem fájl mentés dialógusablakot, a fájlrendszernek csak egy korlátozott elkülönített területét érhetik el, és nem használhatnak WCF szolgáltatásokat sem, mert azok full trustot igényelnek, ellenben használhatnak ASP.NET webszolgáltatásokat. Ám lehetőség van tanúsítvánnyal (certificate) full trustot igényelni az XBAP alkalmazásnak. Összefoglalva előnye a standalone WPF alkalmazásokkal szemben, hogy a felhasználó számára vékony kliens alkalmazásnak látszik, és nem feltétlenül igényel annyi bizalmat a felhasználó részéről, mint egy standalone alkalmazás, hiszen alapértelmezésben a security sandbox védi a felhasználó operációs rendszerét. A korábbi vékony kliens alkalmazásokkal szemben előnye az egyszerűbb fejleszthetőség (beleértve az interaktivitás egyszerűbb megteremtését is), a nagyobb funkcionalitás, jobb vizuális testreszabhatóság, kisebb hálózati terhelés, és a WPF által nyújtott számos egyéb szolgáltatás kiaknázásának lehetősége. A Windows Forms alkalmazásokkal szemben pedig az egyszerűbb telepíthetőség, és a WPF által nyújtott számtalan lehetőség. Az XBAP hátránya, hogy csak WPF támogatással rendelkező Windows operációs rendszereken képes futni. Ezért alkotta meg a Microsoft a Silverlight technológiát (más néven WPF/E, azaz WPF Everywhere), mely a WPF technológia egy részének megvalósítása nem csupán Windows platformra (jelenleg még Macintosh operációs rendszerre). Javascripten és XAML-n alapul. A Flash alternatívája lehet. Tartalmazza a WPF vektorgrafikával, képekkel, videókkal, animációkkal, textrendereléssel kapcsolatos feature-eit. Mozilla Firefox-hoz, Internet Explorerhez és Apple Safarihoz léteznek letölthető kiterjesztések egyelőre.

7 XAML eXtensible Application Markup Language
általános objektumfa példányosító nyelv a felhasználói felület fejlesztéséhez deklaratív felületelemek hierarchiája könnyedén definiálható jól olvasható, tömör kód fejlesztőeszközök fejletlenek még A XAML az eXtensible Application Markup Language (avagy bővíthető alkalmazás jelölő nyelv) rövidítése. XML alapú, így fontos nyelvi szabálya többek között, hogy minden elem nyitótag-jéhez tartoznia kell egy zárótag-nek is, ill. a dokumentumnak pontosan egy gyökérelemmel kell rendelkeznie. A XAML egy általános objektumfa példányosító nyelv a felhasználói felület fejlesztéséhez, az egyes XAML tag-ek osztályokat példányosítanak, a tag-ek attribútumaival pedig az osztályok propertyeit állíthatjuk be. Deklaratív, tehát azt definiáljuk, mit szeretnénk, a hogyanról pedig majd a fordító gondoskodik. Gyorsabban, egyszerűbben fejleszthetünk vele, mintha C# vagy Visual Basic kódban írnánk az alkalmazást, de akár utóbbit is megtehetjük, mert minden funkció elérhető kódból is, nem csak XAML-ből. Előnye többek között, hogy a felületelemek hierarchiába rendezettek, mely tisztán világosan látható, és pusztán a vezérlőelemek XAML-beli elhelyezkedése által definiálható, míg pl. C# kódban meg kell adnunk mind a vezérlőelemek elhelyezését, mind az esetleges hierarchiát. Továbbá jól olvasható és tömör kódot nyújt mind a fejlesztők mind a fejlesztőeszközök számára. Hátránya hogy még nincs módszer a XAML fájlok C# kódfájlokhoz hasonló dekomponálására, valamint a debuggolása nehézkes [5]. Általában XAML-ben implementáljuk a felhasználói felület megjelenítését és C# vagy Visual Basic mögöttes kódban az alkalmazáslogikát. A megjelenítés és logika eme szétválasztása hasonlít az aspx oldalak és codebehind fájljuk szétválasztására, XAML-ben is hasonlóan definiálható a felület kinézete, illetve az adatkötés. A XAML fájlokat a fordító bináris állománnyá fordítja, és egy BAML nevű erőforrás keletkezik, melyet a WPF motor betölt, ebből példányosítja az objektumfát, majd létrehozza a kötéseket [5].

8 XAML Erőforrások Adatkötés Stílusok Sablonok
Az erőforrásokkal objektumokat és értékeket oszthatunk meg vezérlők között, pl. háttérszínt, adat- és vezérlősablonokat, de legtöbbször stílusok definiálására használjuk őket. Futásidőben jönnek létre, és a rájuk hivatkozó elemek osztoznak rajtuk. Az erőforrásokat egy ResourceDictionary (erőforráskönyvtár) objektumban tárolhatjuk. Az adatkötés segítségével egyszerűen kapcsolhatunk össze adatokat vezérlőkkel. Az adatkötés független az adatok megjelenítésétől, utóbbit külön szabhatjuk testre. Egyszerű adatkötés esetén target bármely felületelem bármely propertye lehet, a source pedig bármely object bármely propertye. Listás adatkötés esetében egy listát kötünk hozzá egy vezérőhöz. ((Négyféle adatkötési mód támogatott: OneWay: a target control csak olvassa az adatforrást TwoWay: a target control változása hatással van az adatforrásra, így megvalósíthatjuk, hogy a felhasználó ne csak olvashassa, de írhassa is az adatokat. OneTime: a target control inicializálása a source értéke alapján történik, de ezután már nem követi nyomon a source változását. OneWayToSource: a működése tulajdonképp a OneWay fordítottja, azaz a source frissül a target alapján (de fordítva nem).)) A Binding osztály szintén fontos propertyje a Converter. A Convertereket a propertyk értelmezéséhez használhatjuk fel, ilyen pl. a DMApp projekt Converters mappájában található InverseBooleanConverter osztály, melyet a DMAppStyles-ban definiált myInverseCheckboxStyle stílusban használunk fel arra, hogy az e stílussal definiált CheckBox vezérlők IsChecked propertyének értékét invertálja, tehát a felületen megadott érték ellenkezőjét tudjuk elmenteni az adatforrásba. A Converter osztályban implementálnunk kell az IValueConverter interface-t, és ezáltal a Convert és ConvertBack metódusokat, előbbit a databinding engine akkor hívja meg, amikor egy értéket a source-tól a target-nek adunk át, utóbbit pedig amikor a targettől a source-nak. A stílusok property értékek gyűjteményei, melyekkel a vezérlőket egyszerűen testreszabhatjuk. Segítségükkel amennyiben egy vagy több vezérlőnek azonos propertyket szeretnénk definiálni, elég a beállítani kívánt tulajdonságokat egyetlen stílusban definiálni, és e stílust megadni ezen vezérlőknek.  ÚJRAFELHASZNALHATOSAG A stílusok legfontosabb propertyje a Setters, propertyk és eseménykezelők beállítására hivatott Sablonok: ÚJRAFELHASZNALHATOSAG szintén maga a felület tömör lehet, csakhivatkozásokat trtalmaz stilusokra és templatekre A sablonokkal avagy Template-ekkel a vezérlők megjelenítését határozhatjuk meg. Kétféle sablont különböztethetünk meg, a DataTemplate osztály által nyújtott adat sablont és a ControlTemplate által nyújtott vezérlő sablont. Az adat sablonokkal a vezérlők adatainak megjelenítését szabhatjuk testre, pl. egy ListBoxnak megadhatjuk, hogy tartalmazzon egy Gridet, melyben tetszőlegesen jeleníthetjük meg a hozzákötni kívánt adatokat és pl. még más egyéb szövegeket. . Egy adat sablont természetesen többször is felhasználhatunk az alkalmazásban, elég egyszer definiálnunk azt. A vezérlő sablonokkal pedig testreszabhatjuk a vezérlő teljes vizuális megjelenését és vizuális működését. Utóbbi, azaz a működés triggerek hatására történő propertyváltást takar, így téve interaktívvá vezérlőinket.

9 WCF újgenerációs technológia elosztott alkalmazások fejlesztéséhez
szolgáltatások felépítése: szolgáltatás osztály host környezet végpontok: address (cím) binding (kötés) contracts (szerződések) A korábban Indigo néven futó Windows Communication Foundation (WCF) a .NET 3.0 kommunikációs rétege, egy újgenerációs technológia elosztott alkalmazások fejlesztéséhez. Egyetlen szolgáltatás-orientált modellbe egyesíti az ASP.NET webszolgáltatások, a biztonságos webszolgáltatások (WSE, Web Service Enhancement), a .NET Remoting, a Microsoft üzenetsorok (MSMQ) és az Enterprise Services előnyeit. Három fő részből áll egy WCF szolgáltatás – egy szolgáltatás osztályból, ami a nyújtani kívánt szolgáltatást implementálja (és a hozzá tartozó interface-ből), egy host környezetből, azaz „egy befogadó processből, ami a szolgáltatás számára biztosítja a futtatási környezetet” (ez lehet konzol alkalmazás, windows forms alkalmazás vagy az IIS), és egy vagy több ún. endpointból (végpontból), amihez a kliensek kapcsolódhatnak. Egy szolgáltatás egy vagy több endpointot (végpontot) publikál, a kommunikáció során a kliens üzenetet küld a végpontoknak, illetve az általuk küldött üzeneteket fogadja. Minden endpoint három elemből áll: Address (cím): Hol találom meg a szolgáltatást, azaz hogyan tudják más endpointok felvenni vele a kapcsolatot. Ez egy URL, pl.: Binding (kötés): Hogyan tudom elérni a szolgáltatást, azaz milyen csatornakonfigurációval tudok a végponttal kommunikálni. Meghatározza a transzportot (pl. TCP, HTTP), és a végpont által támogatott magasabb szintű szolgáltatásokat (pl. biztonság, tranzakciókezelés). A WCF előre definiált bindingokat is kínál, de akár sajátot is definiálhatunk. Contracts (szerződések): Mit tud nyújtani számomra a szolgáltatás, azaz a szolgáltatás interface-ének leírása, mely meghatározza a szolgáltatás által kínált műveleteket. Megadható .NET interface-ként vagy wsdl leírásként is. Ha a szolgáltatás interface kódja nem áll rendelkezésre a kliens számára (pl. más platformon futó szolgáltatás, más nyelven írták, stb.), akkor a szolgáltatás által publikált metadata-exchange végpont által érhetjük el a szolgáltatás leírását, erre az implementációs részben láthatunk majd példát. A kommunikáció során a kliens felveszi a kapcsolatot a szolgáltatással, és meghívja egy műveletét. A kérés áthalad a binding által meghatározott kliens oldali Channel Stack-en, az adott bindingnak megfelelő üzenet, majd adatfolyam lesz belőle, majd a transzport közegen át eljut a szerver Channel Stackjéhez, melyen végighaladva az az adatfolyamot visszaalakítja üzenetté, végül a Dispatch Runtime meghívja a szolgáltatás megfelelő metódusát, és az eredmény a szerver oldali Channel Stacken, a csatornán, majd a kliens oldali Channel Stacken keresztül jut vissza a klienshez. Mind a kliens mind a szerver oldali Channel Stack több rétegből áll, e rétegek az adott bindingtól függenek, más rétegekkel találkozunk a WSHttpBinding esetén, mint pl. NetTcpBinding használatakor. Állandónak tekinthető a kliens oldali Channel Stack legfelső rétege, a Channel Proxy, mely fogadja, majd üzenetté alakítja a kliens kérését. Ez az üzenet végighalad a kliens oldali Channel Stack különböző szolgátatásokat (pl. biztonság, tranzakciókezelés) nyújtó rétegein, majd a legalsó, szintén állandó Transport Channel réteg adatfolyammá alakítja az üzenetet, és elküldi a szervernek, aki fogadja

10 IQSYS SOA Architektúra
Az IQSYS SOA keretrendszer szolgáltatás-orientált architektúrán alapuló alkalmazások fejlesztését támogatja, minden kliens és szerveroldal közötti kommunikáció szolgáltatásokon keresztül történik. Ennek számos előnye van, például a biztonsági ellenőrzéssel egyetlen helyen, a szolgáltatásrétegben kell foglalkoznunk, itt történik a felhasználók azonosítása és jogosultságaik ellenőrzése. Valamint e többrétegű architektúra könnyen karbantartható, mert az egyes rétegek által megvalósított funkciókat kicserélhetjük az interface-ek megtartásával anélkül, hogy a többi rétegben foglalkoznunk kellene a változással. Emellett rugalmasan használható a keretrendszer különböző alkalmazások fejlesztéséhez, újrafelhasználható a kód, pl. a Foundation alaposztályait (pl. BaseEntity, BaseView, BaseEnum, stb.) az egyes alkalmazások saját BusinessLogic projektjében felhasználhatjuk, a belőlük származtatott osztályokat a feladatnak megfelelően testreszabhatjuk. Így fejlesztői szempontból igen produktív. A produktivitást az is növeli, hogy minden alkalmazás hasonlóan épül fel, így elég egyszer elsajátítanunk az architektúra ismeretét, és ezután már a többi alkalmazás fejlesztésébe is könnyebben tudunk bekapcsolódni. A keretrendszert több komponens alkotja, ezek: Foundation, DataAccess, Configuration, UserInterface. Ezekre építjük rá az egyes alkalmazások saját rétegeit azok felhasználói felületének, üzleti logikájának, üzleti objektumainak és üzleti szolgáltatásainak megalkotásához. Mind vékony kliens, mind vastag kliens alkalmazások fejlesztéséhez rendelkezésre áll a keretrendszer, WPF alkalmazásokhoz pedig már részben elkészült, és folyamatosan bővül. Az adatbázisban tárolt vagy újonnan létrehozott üzleti objektumok (entitások és mezőik) reprezentációja a szerver és kliens oldalon egységes. Az üzleti objektumok az üzleti szolgáltatások segítségével érkeznek a kliens oldalra, majd így is jutnak vissza szerveroldalra módosítás esetén. A Foundation tartalmazza a nem felhasználói felület jellegű alaposztályokat. Például üzleti objektumokat reprezentáló, mezőkkel rendelkező entitásokhoz (Entities), listázó vezérlők adatforrásául alkalmazott, adott feltételeknek megfelelő üzleti objektumok példányainak felsorolására szolgáló enumokhoz (Enums), hierarchikus adatokat reprezentáló fákhoz (Trees), és Gridek adatforrásául szolgáló nézetekhez (Views). A DataAccess projekt által megvalósított adat réteg az adatbázis írását és olvasását teszi lehetővé a magasabb szintű rétegek számára. A Configuration projekt segítségével a felhasználói és alkalmazásszintű beállításokat érhetjük el. A UserInterface felhasználó felület kialakításához nyújt alapokat, erre építhetjük az alkalmazás saját felhasználói felületét. Tartalmaz többek között egyedi fejlesztésű Controlokat és FieldControlokat, valamint tipikus feladatokat megvalósító felületek alaposztályait. Előbbire jó példa a listázó oldalakon található, táblázatok megjelenítésére szolgáló Grid vezérlő, mely egy View elemeit képes megjeleníteni, azokat a Grid tetszőleges oszlopa szerint sorbarendezni, és az oszlopok mérete is tetszés szerint igazítható.

11 Iratkezelő rendszer A teljes iratkezelő rendszer hat önálló alkalmazásból épül fel: Adminisztrációs kliens: A rendszeradminisztrátori funkciókat tartalmazó kliens. Iratkezelő kliens: A rendszer általános iratkezelési funkcióit és a szervezeti adminisztrációs funkciókat tartalmazó kliens. Központi érkeztető kliens: Az érkeztetési és központi ügyféltörzs karbantartási funkciókat tartalmazó kliens. A postai úton érkező iratok érkeztetése itt történik. Outlook AddIn: A Microsoft Outlookból történő iktatást lehetővé tevő Outlook bővítmény. Iratkezelési szolgáltatások: Az iratkezelő rendszer üzleti funkcióit a külvilág és a többi rendszerösszetevő felé publikáló ASP.NET webszolgáltatások, melyeket az új alkalmazásban WCF szolgáltatások váltanak fel. AD Szinkron: Az adatbázis és az Active Directoryban tárolt iktatóhelyek szinkronját biztosítja. A prezentációs réteg a felhasználóval való interakció biztosítására hivatott. A feladat megvalósításához az új prezentációs réteget a korábbi vastag klienses UserInterface komponens helyett az új WPF-es UI komponensre kell építeni. Az új prezentációs réteget a UserInterface projekt, és az őt felhasználó DMApp projekt tartalmazza, mely az kliens alkalmazás magját adja. Az új üzleti réteg iratkezelési szolgáltatásai a korábbi ASP.NET webszolgáltatások helyett WCF szolgáltatásokat használnak a rendszer üzleti funkcióinak biztonságos publikációjára. (Az üzleti komponensek felelősek a rendszer által megvalósított üzleti funkciók végrehajtásáért. pl entitások pldositása) (Az üzleti entitások teszik lehetővé az egyes üzleti objektumokhoz kapcsolódó adatok reprezentációját és rétegek közötti átadását. Az iratkezelő rendszerben használt üzleti entitások egyedi leképezését adják az üzleti objektumoknak. ) Az adatokhoz való hozzáférést biztosítja a magasabb rétegek számára. Ezt a réteget nem szükséges újra implementálni, változtatás nélkül támaszkodhatok a szolgáltatásaira. (pl. entitásokat tölti fel adatokkal) Az alkalmazásnak a vállalatoknál gyakori intranetes környezethez kell alkalmazkodnia, de természetesen megvalósítható lenne internetes környezetre is. A felhasználók azonosítása ezért az intranetes környezetben jól alkalmazható Windows Integrated Security segítségével fog történni. A felhasználó által végrehajtható műveletek körét a felhasználó privilégiumai határozzák meg. A felhasználó privilégiumait szerepköri tagságai határozzák meg, ugyanis az egyszerűbb adminisztráció érdekében a privilégiumokat szerepkörökhöz rendeljük, és e szerepköröket rendelhetjük a felhasználókhoz. A privilégiumok csak megengedőek lehetnek. A privilégiumok közvetlenül a szerver oldali szolgáltatásokhoz való hozzáférést szabályozzák. A privilégiumok közvetve a menüpontok láthatóságát is befolyásolják, minden menüpont

12 Elvárt funkcionalitás
dossziérendszer kategóriarendszer iktatókönyv inbox és outbox nézet feladatlista beosztottak feladatlistái és tevékenységei iratkezelési folyamatok megvalósítása Az alkalmazás az iratokat iktatószervezet szinten kialakított dossziérendszerben fogja tárolni logikailag. A strukturális tárolás megkönnyíti a dokumentumok keresését. A fő-dossziék kinyitogathatóak lesznek al-dossziékra A dosszié struktúrán túl az iratkezelő alkalmazásnak egy ún. kategória rendszer segítségével is támogatnia kell az iratok megjelenítését. Közp, szem. A felhasználó hozhasson létre új személyes és központi kategóriákat, módosíthassa őket vagy akár törölhesse is azokat. Az iratkezeléshez nélkülözhetetlen elektronikus iktatókönyv bármely évre legyen lekérdezhető, melyhez tartozik irat. Ez a Lekérdezések menüpont Iktatókönyv menüpontjában lesz fellelhető. Minden iktatóhely rendelkezzen egy Inbox nézettel, ide kerüljenek a Központi Érkeztetőből jött, külső cégektől érkezett, és a más iktatóhelyektől érkezett iratok. Minden iktatóhelynek rendelkeznie kell egy Outbox nézettel is, ahová a külső cégeknek és a más iktatóhelyeknek címzett iratok kerüljenek A felhasználó a feladatlistájában tekinthesse meg azon iratokat, melyeknek ő a felelőse. A vezetőknek legyen lehetősége megtekinteni a beosztottjaik feladatlistáját és tevékenységeit Meg kell valósítanunk a következőkben ismertetett iratkezelési folyamatokat és az iratokat megtestesítő irat adatlapot. A rendszerben öt testreszabható iratkezelő folyamat van, a bejövő irat/fax (iktatás, ügyintézés, lezárás, aktiválás, sztornózás végezhető rajta), a bejövő (iktatás, ügyintézés, lezárás, aktiválás, sztornózás végezhető rajta), a kimenő irat/fax (iktatás, ügyintézés, kiadmányozás, postázás, lezárás, sztornózás műveletekkel), a kimenő (iktatás, lezárás, sztornózás tevékenységekkel) és a belső irat (iktatás, ügyintézés, lezárás, sztornózás tevékenységekkel). Bejövő irat/fax folyamatot indíthatunk bejövő irat/fax iktatással, vagy az inboxból iktatással, vagy egy kimenő irat/fax folyamathoz tartozó irat válaszirat funkcióját választva. Bejövő, kimenő folyamat az Outlookból való iktatással keletkezik Kimenő irat/fax folyamatot indíthatunk kimenő irat/fax iktatással, vagy bármely folyamathoz tartozó iraton a kimenő másolat funkció választásával, vagy egy bejövő irat/fax folyamathoz tartozó irat válaszirat funkciójával. Belső irat folyamat belső irat iktatással vagy egy belső irat válaszirat funkciójával hozható létre. Az ilyen irat az iktatószervezet határán belül mozog. Az iktatószervezet iratkezelési és adminisztrációs szempontból összetartozó iktatóhelyek halmaza. Az iktatóhely az iktatószervezeten belüli iktatatási pont, mely a vállalat bármely szervezeti egysége lehet. Az iktató szervezetet alkotó iktatóhelyek hierarchia szempontjából egymás mellé rendeltek. Egy iktatóhely csak egy iktatószervezethez tartozhat egyidőben. Iktató szervezetenkénti folyamatos sorszámozású iktatási szisztéma fog érvényesülni a rendszerben. Az egy iktató szervezet alá tartozó iktatóhelyek közös iktatótömbbel, adminisztrátorokkal, szerepkör- és dossziéstruktúrával és irattípusokkal rendelkeznek. A felhasználókat egy vagy több iktatóhelyhez rendeljük.

13 WCF szolgáltatások host környezet: IIS
szolgáltatás osztályok implementálása konfigurálás szolgáltatások hívása WCF szolgáltatásainkat az Internet Information Services (IIS) segítségével hosztoljuk Első lépésként a Contractot valósítottam meg, azaz alkottam egy .net interface-t (pl. ilyen az IDocumentCards), és servicecontractként definiáltam azért, hogy WCF service-ként kerüljön publikálásra. Az interface-ben definiált metódusokat pedig OperationContractként kellett definiálnom ahhoz, hogy publikálásra kerüljenek a szolgáltatásban, „részévé váljanak”. Pl.: [OperationContract] void SendBack(int documentCardID, string remark); Ezután létrehoztam egy osztályt, mely implementálja a fenti interface-t webconfig: definiálnunk kell minden szolgáltatáshoz egy hozzá tartozó URI báziscímet, ezen a címen lesz elérhető az adott szolgáltatásunk végpont address, binding, contract és behaviorConfiguration attribútumaiban a végponttal kapcsolatos beállításokat adjuk meg: Az addressel a báziscímhez képest relatív elérési címet adhatunk meg (hozzáadódik a báziscímhez), a contract az interface fully-qualified name-jét tartalmazza, a binding a használt kötést, a behaviorConfiguration-ben pedig a <behavior> tag alatt található withMessageInspector endpointBehavior-re utalunk, mely egy endpointMessageInspector behaviorExtension-t tartlamaz (lásd a <system.serviceModel> <extensions> tag-jét), ezzel adjuk meg, hogy használja a MessageInspector osztályt. A MessageInspector osztály a szolgáltatás requestek elküldése előtt csinál egy új üzenetfejlécet, és beleteszi a kliens CurrentOrganizationUnitID-ját, így mellékelve minden szolgáltatáshívás SOAP borítékjába a felhasználó jelenlegi iktatószervezet azonosítóját, illetve ő foglalkozik azzal, hogy a service requestek beérkezése után kiolvassa ezen CurrentOrganizationUnitID-t és eltegye a UserInfo CurrentOrganizationUnit-jába. Továbbá minden szolgáltatáshoz definiálunk egy további, metadata-exchange végpontot, mely segítségével majd a kliens le fogja tudni generálni a proxy osztályt (és engedélyezzük a behaviorben a metaadatok publikálását). A kliens alkalmazáshoz service reference-ként hozzáadjuk az elérni kívánt szolgáltatásokat. Így a Visual Studioba integrált Service Model Metadata Utility a metadata-exchange végponthoz kapcsolódva megkapja az adott szolgáltatás WSDL-ét, és ez alapján legenerál egy osztályt, mely tartalmazza a szolgáltatás meghívásához szükséges interfaceleírást (pl. ilyen a DocumentManagement_EntitiesService.cs-ban az IEntities interface), és a proxyt, mellyel majd meghívhatjuk a szolgáltatást. Utóbbira példa a DocumentManagement_EntitiesService.cs-ban az EntitiesClient osztály. A BusinessLogic/DocumentManagement illetve General mappa Services.cs fájljaiban található Service osztályokban minden szolgáltatásnak létrehozunk egy statikus proxy osztály példányt, amit egy szintén statikus publikus propertyn keresztül teszünk elérhetővé, mely visszaadja a proxy példányunkat, de ha esetleg nem létezik vagy már bezárt állapotban van a proxynk, előbb újra létrehozza azt. Ezt használjuk a szolgáltatás metódusainak hívásához, először megnyitjuk azt, utána történhet a metódushívás, végül bezárjuk. Pl. az entitiesClient proxyt visszaadó Entities property esetén:

14 Kliens A DMApp projektben valósítjuk meg a kliensalkalmazást. XBAP-ként fordítjuk, hogy az Internet Explorer meg tudja jeleníteni. Alkalmazásunk XBAP létére full trust-ot igényel kliensünk gépén, hiszen számos olyan korlátot lép át a második fejezetben említettek közül, amelyet enélkül nem tehetne meg, ilyen például a Windows Forms vezérlők hosztolása. A full trust-ot egy általunk kiállított tanúsítvány (certificate) segítségével kapja meg, mellyel fordításkor aláírjuk a kódot, és a kliensek ezt a tanúsítványt importálják megbízva abban. Ezt nem kell egyenként megtenniük, elég a vállalat tanúsítvány könyvtárába importálnunk a tanúsítványt. Az alkalmazás főmenüjének egy elemét kiválasztva a főablak jobb oldali részére betöltődik egy oldal. Ez többnyire egy listázó képernyő, mely egy Gridben jelenít meg egy nézetet, s a Grid egy-egy elemének kiválasztásakor a Grid felett található funkciósorban megjelennek az adott elemmel az adott felhasználó által végezhető műveletek, például létrehozás, módosítás, törlés, stb. Ha egy műveletre rákattintunk (vagy a jobb egér gombbal megjelenő funkciók közül kiválasztjuk), meghívódik az adott funkció Execute metódusa. Számos ilyen funkció egy dialógusablakot dob fel, melyen az adott sorhoz tartozó entitás mezői szerkeszthetőek vagy pl. új entitás hozható létre. Az iratkezelési műveletek során az entitás mezőinek esetleges szerkesztésén túl az iratkezelő folyamatok állapotátmeneteinek végrehajtásáról is gondoskodnunk kell. Az entitások mezőit vezérlőelemekhez kötjük, ezek lehetnek a WPF által nyújtott vezérlők, vagy a UserInterface projektben található, a cég által fejlesztett vezérlők. Az alkalmazás főablakának bal oldalán található a felhasználóhoz tartozó menü. A menü egy elemét kiválasztva az ablak jobb oldali részére töltődik be a kiválasztott menüelemhez tartozó oldal a PageContainer vezérlő segítségével. Szintén a jobb oldalon e felett egy Caption felirat található, a PageContainer alatt pedig egy Status felirat, melyek tartalma a betöltődő oldalaktól függ. A főablak legalján pedig az alkalmazás verziószámát és az aktuális felhasználó nevét írjuk ki.

15 Kliens egyszerű listázó oldalak menüelem paramétereinek kiolvasása
kívánt funkciók hozzáadása funkciók gyűjteményét a FuncionContainer-hez adjuk hozzárendeljük a helyi menühöz a funkciókat a helyi menüt az oldal Gridjéhez kapcsoljuk megadjuk a Gridhez tartozó View-t, így egy adatbázistábla sorainak részhalmazát megjelenítjük

16 Kliens funkciók és entitás dialógusablakok:
funkciók megjeleníthetnek egy Windowt, mely BaseEntityDialog ősű is lehet, entitás adatait szerkeszthetjük (pl. irat adatlap), megtekinthetjük (pl. élettörténet) dialógusablakokon field vezérlők az entitás mező típusának megfelelően (pl. StringFieldhez TextBox)

17 Irat adatlap A listázó oldalak jórészén találhatóak iratkezelő funkciók, melyek kiválasztásakor megjelenik az aktuálisan kiválasztott irat adatlapja. Az irat tulajdonságainak megtekintésekor is az irat adatlappal találkozunk. Az irat adatlap egy a főablakhoz hasonló kinézetű ablak, szintén található benne egy menü, mely egy-egy elemének kiválasztásakor az ablak jobb oldali részébe betöltődik az adott menühöz tartozó oldal, ahol megtekinthetjük, illetve adott esetben szerkeszthetjük is az entitásunk mezőit, majd miután végeztünk a módosításokkal, az irat adatlap alsó részében található ’Ok’ vagy ’Mégsem’ gombbal menthetjük vagy vethetjük el az esetleges változásokat.

18 Fejlesztés nehézségei
kevés fellelhető szakirodalom iratkezelő: kevés comment a kódban XAML: designer nézet hiánya, intellisense működésképtelensége Visual Studio gyakran működésképtelenné válik debuggolás után