RESTful web-szolgáltatások készítése WCF-ben

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "RESTful web-szolgáltatások készítése WCF-ben"

Átírás

1 Szegedi Tudományegyetem Informatikai Tanszékcsoport Diplomamunka Készítette: Pótári Tamás Programtervező informatikus MSc Témavezető: Dr. Alexin Zoltán Egyetemi adjunktus Szeged 2011

2 Feladatkiírás Napjaink kisvállalkozásai a kereskedelmi szférában egy webshop-pal, illetve egy ettől független vagy szerencsésebb esetben ezzel összhangban lévő számlázó és raktárkészlet nyilvántartó alkalmazással kezdik tevékenységüket az internet nyújtotta végtelen piacon. Idővel viszont a rendelkezésre álló informatikai megoldás kevésnek bizonyul számukra. Így szükségük lesz egy komolyabb kereskedelmi rendszerre, mellyel bővíthetik lehetőségeiket a mindennapi versenyben. Erre a problémára az ERP-k nyújtanak megoldást, melyekből rengeteg található a piacon. A diplomamunkám egy tipikus problémakörre koncentrál, ami legtöbbször egy ERP bevezetése előtt, vagy éppen bevezetés közben szokott jelentkezni. A valamirevaló ERP-k rendelkeznek webes felülettel, hétköznapian fogalmazva: webshop-pal. De megeshet, hogy ez a webshop nem elégíti ki a megrendelők igényeit, ezért át szeretnék azt alakíttatni az ERP szállítójával. Sőt felmerülhetnek olyan igények is, hogy az új ERP rendszert összekössék a bevált, vásárlók számára jól ismert, korábbi webshop-jukkal. Az összekapcsolás rendkívül kényes kérdés. Miután tisztázták a felek a két (vagy több) rendszer kommunikációjának sarokpontjait, irányát, gondoskodniuk kell a technológiai akadályokról is. A két rendszer ugyanis nagy valószínűséggel egymástól teljesen eltérő platformon működik, így a fejlesztők kommunikációja is nehézkes. De mégis egy elvi kérdés a legnyugtalanítóbb, miszerint egy ERP szállító, a termékük adatbázisát és üzleti logikai rétegét nem szívesen teszi közzé egy másik cég számára. A megoldás egy API. Diplomamunkám célja egy meglévő és működő, webes kereskedelmi rendszer kibővítése web-szolgáltatásokkal az imént említett API megvalósítása érdekében. Így könnyedén össze lehet kötni más rendszerekkel, a korábban említett problémákat áthidalva. Mivel a kereskedelmi rendszer Microsoft.NET alapú, ezért a WCF technológiával implementálom az API-t, mint RESTful szolgáltatások halmaza. Bemutatom a szóban forgó kereskedelmi rendszer főbb szolgáltatásait. Részletekbe menően szemléltetem a modellezés, az implementálás, a beüzemelés és a tesztelés minden lépését. A fejlesztési folyamat rendkívül széles technológiai látókört igényel; a REST világ, a Microsoft WCF, a Microsoft SQL Server, IIS7 és a.net komponensorientált programozás, csakhogy néhány témakört említsek. Ezek legtöbbjét, szükségszerűen be is mutatom, sőt elismert fejlesztők és szakértők tervezési módszereit, technikáit alkalmazom. Betekintést biztosítok a REST és RESTful világba majd a WCF érintett szegmensébe. 2

3 Az elkészített web-szolgáltatásokat akár más szoftverrendszerek is felhasználhatják, szemléltetni is fogom ennek lehetőségeit. Továbbá a kereskedelmi rendszer az új API segítségével nagy előnyre tesz szert az ERP-k piacán, mivel még napjainkban is alig-alig találkozni jó megoldásokkal. 3

4 A téma megnevezése: Tartalmi összefoglaló A megadott feladat megfogalmazása: A cél, egy meglévő és működő, Microsoft.NET alapú webes kereskedelmi rendszer kibővítése web-szolgáltatásokkal, és ezen keresztül a RESTful szolgáltatások előállítási lehetőségeinek bemutatása Microsoft WCF-ben. A megoldási mód: A RESTful architektúra stílus útmutatóját követve történik a tervezés, a kivitelezés pedig Microsoft WCF-ben, C# nyelven. A kibővítendő kereskedelmi rendszer komponensei lettek újrahasznosítva. A tesztelés, beüzemelés és optimalizálás szintén Microsoft eszközökkel zajlott. Alkalmazott eszközök, módszerek: A fejlesztés Microsoft.NET 4-ben, C# nyelven zajlott WCF WebHttp szolgáltatásokkal. A fő fejlesztőeszköz a Visual Studio 2010 (Ultimate) volt, továbbá a tesztelés is a Visual Studio Web Performance Test megoldásaival valósult meg. A dolgozatban bemutatásra került a kibővített alaprendszer érintett szegmense is. A RESTfult architektúra stílus erőforrásorientált tervezési útmutatója lett alkalmazva. A módszerek és minták javarésze elismert szakírók által alátámasztottak, továbbá az egyedi ötletek részletesen be lettek mutatva. Elért eredmények: A kívánt RESTful szolgáltatás elkészült, dokumentálva lett, átesett egy automatizált tesztelésen, telepítve és teljesítmény tesztek útján optimalizálva lett. Az elkészült terméket a dolgozat születése közben már felhasználta egy másik web-es szoftver. A kialakítás és a kommunikáció röviden be lett mutatva. Kulcsszavak: REST és RESTful szolgáltatások, Microsoft WCF WebHttp szerveroldali megoldások, Data Contract sorosítás, API kulcsos hitelesítés, gyorsítótárazás, komponens-orientált programozás, Visual Studio Web Performance Test, IIS 7.5, ASP.NET 4, SQL Server

5 Tartalomjegyzék 1. BEVEZETÉS A REST VILÁG A SOAP A REST A RESTFUL-SÁG REST A GYAKORLATBAN Az erőforrások meghatározása Az URI-k megtervezése Az egységes interfész implementálása A reprezentáció megtervezése Kapcsolatok kialakítása TERVEZÉSI MINTÁK, SPECIÁLIS MEGOLDÁSOK Tervezési minták erőforrásokhoz A WCF RESTFUL PROGRAMOZÁSI MODELLJE WCF A SZERVEROLDALON A WEBHTTP SZOLGÁLTATÁSOK A WCF WebHttp szolgáltatások adottságai fejlesztői szempontból A DATA CONTRACT SOROSÍTÁS Deklaratív programozás Öröklés és interfészek implementációi Hivatkozások és körkörös hivatkozások Verzió tolerancia Null és üres értékek Gyűjtemények Néhány sajátosság AZ ALAPRENDSZER ISMERTETÉSE AZ ÉRINTETT SZERELVÉNYEK ISMERTETÉSE A RENDSZER NÉHÁNY FONTOS TULAJDONSÁGA Interfészek és implementációik Komponens alapú biztonság A lokalizáció Példányosítás, mentés, törlés és listázás KIVITELEZÉS A REST WCF PROJEKT LÉTREHOZÁSA AZ ERŐFORRÁSOK MEGHATÁROZÁSA Az érintett témakörök Kompozitok A közös interfész AZ URI-K MEGTERVEZÉSE Az URI template-ek megtervezése Az URI template-ek implementálása AZ EGYSÉGES HTTP INTERFÉSZ IMPLEMENTÁLÁSA A REPREZENTÁCIÓ MEGTERVEZÉSE A Data Contract dekoráció és részleges objektumok A kívánt reprezentáció megadása Nagyobb gyűjtemény jellegű erőforrások lapozhatósága ÖSSZEKAPCSOLHATÓSÁG A Link-ek inicializálása Link relációk HITELESÍTÉS Az API kulcsos hitelesítés implementálása ÁLLAPOTKÓDOK

6 Globális hibakezelés A 201 státusz kód DOKUMENTÁCIÓ Help Link-ek az erőforrásokban TESZTELÉS Egységtesztek Teszteredmények Egy kis technológiai affér TELEPÍTÉS ÉS OPTIMALIZÁLÁS IGÉNY A SZOLGÁLTATÁSA Kialakítás és kommunikáció GYORSÍTÓTÁRAZÁS A átmenetileg tárolható erőforrások meghatározása A cache-elés beállítása A hitelesítés Terhelésteszt ÖSSZEFOGLALÁS I. SZ. MELLÉKLET IRODALOMJEGYZÉK NYILATKOZAT... HIBA! A KÖNYVJELZŐ NEM LÉTEZIK. 6

7 1. Bevezetés Diplomamunkámmal célom, hogy egy meglévő és működő, Microsoft.NET alapú webes kereskedelmi rendszert kibővítsek web-szolgáltatásokkal, és ezen keresztül bemutassam a RESTful szolgáltatások előállításának módjait Microsoft WCF-ben. Az elkészült termékkel könnyedén össze lehet kötni az alaprendszert más rendszerekkel, áthidalva a platformok közötti differenciákat és a kényes biztonsági kérdéseket. A diplomamunka első fejezeteiben bemutatom a REST alapvető koncepcióját és az ilyen architektúrájú szolgáltatások előállításának elméleti és gyakorlati módját. Majd ismertetem a WCF érintett szegmensét, csakis a kiszolgálóoldalra koncentrálva. Bemutatom a szóban forgó kereskedelmi rendszer érintett részegységeit, továbbá azt is, hogy milyen apróbb módosításokat kellett alkalmaznom azokon a szolgáltatás kivitelezését megelőzően. Majd részletesen szemléltetem a kivitelezés minden lépését a dolgozat elméleti bevezetőjére építve. A dolgozat utolsó fejezetei a dokumentálást, a tesztelést, a telepítést és az optimalizálást részletezik. Nagy kihívást jelentett egy koros és nagyméretű rendszert kibővíteni modern technológiájú megoldásokkal. Számtalan zsákutcába tévedhetnek a tervezők ilyen esetben, és gyakran ekkor születnek a költséges félmegoldások. Legtöbbször ugyanis újabb eszközökkel fejlesztett, modernebb szemléletű rendszereknél kisebb kockázattal kell számolniuk a szakembereknek. Dolgozatommal igazolom, hogy régebbi.net-es rendszereket is hatékonyan fel lehet készíteni a jövő igényeire. Az elkészített web-szolgáltatásokat akár más szoftverrendszerek is felhasználhatják, szemléltetni is fogom ennek lehetőségeit. Így a kereskedelmi rendszer az új API segítségével nagy előnyre tesz szert az ERP-k piacán, mivel még napjainkban is alig-alig találkozni jó megoldásokkal. 7

8 2. A REST világ A REST (Representational State Transfer) rendkívül széles körben alkalmazott megoldás. A Google, a Microsoft Azure, az Amazon, a Facebook, a Twitter, a Flicker, a Digg rendszerek rendre rendelkeznek REST API-val. De technológiákat is említhetünk, amelyek használják, vagy épp speciális implementációjuk a REST szolgáltatásoknak: ilyen az RSS, az Atom. Nem is meglepő, hogy a Microsoft vezető technológiái is támogatják a REST szolgáltatásokat; a WCF, a korábbi ADO.NET Services és a Silverlight. A fejezet célja, hogy bemutassam a REST-et és segítsem a ráhangolódást az erőforrás orientál gondolkodásra, a ROA-ra (Resource-Oriented Architecture) [1]. A továbbiakban néhány elemi tény fog felmerülni, amivel már szinte minden ember megismerkedett, aki valaha is használta a webet. A web legfontosabb tulajdonságai, ami miatt olyan gyorsan elterjedt, a következők: Címezhető erőforrások (URI-kkel) Standard erőforrás formátumok Egységes felület (uniform interface) az erőforrások használatához Állapotnélküliség az ügyfél és a kiszolgáló interakciója között Hiperhivatkozások (összekapcsolás), melyek segítségével navigálhatunk az erőforrások között Ezek a tulajdonságok teszik oly naggyá a webet. Mégis amikor web-szolgáltatásokról beszélünk, a legtöbb szakembernek a SOAP-alapú szolgáltatások jutnak eszükbe, holott a SOAP egyáltalán nem a webre született A SOAP A SOAP-ot tipikusan a távoli eljáráshívásra használják. Azt írja le és valósítja meg, hogy két végpont miként kommunikálhat. Továbbá úgy tervezték, hogy protokoll-független legyen. Ezért bátran kijelenthetjük, hogy nem feltételül a web az a csatorna, amin a SOAP érvényesülhet, mivel elméletileg nem csak a weben működhetne. Emiatt nem használja ki a web legfontosabb tulajdonságait. Például a SOAP szolgáltatások nem az URI-kre összpontosítanak, inkább a műveleteket helyezik előtérbe. Legtöbbször egyetlen URI-hez lesznek felsorakoztatva az elvégezhető műveletek. Így az 8

9 erőforrások összekapcsolása, mint a web talán legfontosabb tulajdonsága, háttérbe szorul, mivel SOAP szolgáltatásokat kevésbé érdemes hivatkozásokkal összekötni. Szintén érdekes dolog, hogy minden alkalommal, amikor egy SOAP szolgáltatást tervezünk, egy új interfészt készítünk, és ennek az interfésznek a későbbi módosítása könnyen befolyásolhatja a szolgáltatást felhasználó rendszerek működését. Illetve nem szabad megfeledkeznünk arról sem, hogy a SOAP szolgáltatások tipikusan a HTTP POST műveletét alkalmazzák, melynek hatása sehol nincs definiálva legalábbis a HTTP-ben nincs, azaz nem egyértelmű az eredményük. Továbbá a SOAP szolgáltatások nem jól gyorsítótárazhatók, mert legtöbbször nem támogatják a GET műveleteket [2] A REST A REST egy architektúrális stílus, egy tervezési szempont web-szolgáltatások 1 készítéséhez, ami 100%-ban a HTTP-re épült. Azaz annak minden tulajdonságát kihasználja, továbbá útmutatót nyújt a REST alapú szolgáltatások előállításához is. A SOAP nem architektúra stílus, semmilyen megszorítást vagy útbaigazítást nem ad, hogy egy szolgáltatás hogyan nézzen ki. Ellenben a REST szolgáltatások a REST előírásait követik. Míg a SOAP szolgáltatások inkább a műveletekre koncentrálnak, a REST szolgáltatások inkább az erőforrásokat veszik alapul, azaz erőforrások útján kommunikálnak a felek. Minden erőforrás egy egyedi URI-vel van beazonosítva. A felhasználó legyen az egy alkalmazás vagy egy internetes böngésző előtt ülő személy a HTTP egységes interfészét alkalmazza az URI által beazonosított erőforrás használatakor. Tehát a REST szolgáltatások inkább főnevekkel (pl.: erőforrások) foglalkoznak, míg a SOAP szolgáltatások igékkel (HTTP és SOAP műveletek) [3] A RESTful-ság Azok a web-szolgáltatások, melyek a REST architektúrális stílust követik, RESTful szolgáltatások. Leonard Richardson és Sam Ruby voltak, akik elsőnek összefoglalták a RESTful szolgáltatások lényegét. A későbbiekben rengeteg szakkönyv jelent meg a témakörben, általános témákkal és technológiákhoz specializált témákkal, mint a Java, Ruby, 1 Továbbiakban, a dolgozatomban a web-szolgáltatás alatt a REST szolgáltatásokat fogom érteni. A SOAP szolgáltatások továbbra is SOAP szolgáltatásokként fogom megnevezni. 9

10 PHP és nem utolsó sorban a.net. A dolgozatom részben ezekből táplálkozik. A RESTfulság előírásainak bemutatása könyveket emészt fel, ezért dolgozatomban csak az általam érintett megoldásokon keresztül írom le azokat. A szakirodalomban és a fejlesztők kommunikációjában gyakran találkozni azzal a kijelentéssel, hogy egy bizonyos problémára egy megoldás, nem teljesen vagy teljes egészében RESTful. A dolgozatomban is számos alkalommal teszek ilyen említést. Arra, hogy egy problémára hogyan találok RESTful megoldást, a korábbi tapasztalataim, a szakirodalom és a fejlesztői kommunikációk nyújtanak tudományos segítséget, továbbá a józan és egyszerű gondolkodás REST a gyakorlatban A REST világgal történő ismerkedéskor érdemes a weboldalakból kiindulni. Bizonyos értelemben egy weboldal is egy REST szolgáltatás. A fejezetben bemutatom, hogy a REST szolgáltatások tervezésekor mely lépéseket kell elvégezni, továbbá kifejtem az alapvető fogalmakat. Szintén kitérek a szigorúbb RESTful szolgáltatások előírásaira is Az erőforrások meghatározása Az erőforrás egy olyan valami, ami tárolható egy számítógépen és reprezentálható bitek folyamaként. Azaz lehet egy dokumentum, egy adatbázis egy rekordja vagy épp egy algoritmus eredménye. Továbbá egy erőforrás lehet egy fizikai objektum, mint egy alma, vagy épp egy absztrakt fogalom is, viszont ezen erőforrások megjelenítése kissé problémás lehet. Nagyvonalakban állíthatjuk, hogy vannak dinamikus és statikus erőforrások. Erőforrások lehetnek a következők: Cikk a Silverlight 4-ről Útvonalterv az iskola és az otthonom között Dokumentáció a Microsoft SQL Server 2008 R2-höz Szoftverfrissítés a Windows 7-hez Ismerőseim a Facebook-on A következő öt prímszám 1024 felett A 223-as rendelés tételei 10

11 REST szolgáltatások tervezésekor az első és legfontosabb lépés az erőforrások meghatározása. Tehát meg kell kérdeznünk magunktól, hogy mik azok a dolgok, amiket közzé szeretnénk tenni. Ezekre először csak összemosódott adathalmazokként tekintünk, majd később ezeket pontosítjuk és átalakítjuk erőforrásokká. [4] [5] Az URI-k megtervezése Az erőforrást az teszi erőforrássá, hogy azonosítható URI-vel. Tehát minden erőforrásnak kell lennie URI-jének, legalábbis a weben igen. Fontos, hogy az URI-k leírók legyenek, így még pontosabb lesz a kapcsolat az erőforrás és annak URI-je között. Továbbá ha az URI jól olvasható, értelmezhető akár az ember számára is, akkor könnyedén lehet vele dolgozni. Az is széppé teszi a munkát, hogy egy erőforrásnak akár több URI-je is lehet, így ha szeretnénk más és más nézőpontból is vizsgálhatjuk ugyanazon erőforrásokat. Lehetséges URI-k: (REST a wiki-n) (A 223-as rendelés) stb. Az URI-k létrehozása a következő lépés a tervezési folyamatban. Mondhatni ez a munka oroszlán része. A pontos URI design nélkülözhetetlen a tervezési folyamat további lépéseire, illetve a kész szolgáltatások felhasználhatóságára nézve. Itt nevezzük el a korábban meghatározott erőforrásokat. Fontos feltétel, hogy az URI megmagyarázza, hogy pontosan micsodán és miért fog dolgozni a kiszolgáló számítógép. Az erőforrás-uri leképezés legfontosabb szabályai: Használjunk útvonal változókat (path variable) a hierarchia leképezéséhez: /parent/child. Használjunk írásjeleket az útvonal változókban, ahol nem tudunk hierarchiát alkalmazni:/parent/child1;child2. Néhány esetben számíthat az útvonal változók sorrendje. Ekkor többféle írásjelet használunk, de tipikusan a vesszőt és pontos vesszőt. Használjunk lekérdezési változókat (query variable), mint algoritmus paraméterei, ha algoritmikus erőforrásról beszélünk: /search?q=akarmi&start=20. [6] [7] 11

12 Az egységes interfész implementálása Mint korábban említettem, egy SOAP szolgáltatás tervezésekor műveleteket hozunk létre. Valójában ekkor egy interfészt tervezünk az alkalmazásunknak. De ez az interfész nem egységes, hiszen teljesen másképp néz ki, mint egy másik cég által fejlesztett rendszer SOAP szolgáltatása. De akár ugyanezen a rendszeren belül egy másik SOAP szolgáltatás is teljesen eltérő felülettel rendelkezhet. A probléma tehát, hogy az egységesség híján állandóan új interfészek megalkotásán kell gondolkozniuk a SOAP szolgáltatás fejlesztőknek. Másfelől ha egy másik cég fejlesztője szeretné használni a szóban forgó SOAP szolgáltatást, akkor meg kell tanulnia ezt az interfészt, és gyakran azt is, hogy milyen hatásai vannak a benne tartalmazott műveleteknek. A REST-nél szerencsére másképp van. Itt a HTTP által definiált műveleteket más szóval igéket, vagy verbs-öket használjuk az URI-k által azonosított erőforrásokon. Ezek a műveletek alkotják az egységes interfészt (1. ábra) [8]. GET Visszaad egy erőforrást Garantáltan nincs mellékhatása (SAFE) Gyorsítótárazható POST Létrehoz egy új erőforrást Nem biztonságos, a művelet hatása nincs pontosan definiálva a HTTP által (RFC 2616) PUT Módosít egy létező erőforrást Ha ismert az URI, akkor erőforrás létrehozásához használjuk Akárhányszor hívjuk, mindíg ugyanaz fog történni (idempotens) DELETE Eltávolít egy erőforrást Akárhányszor hívjuk, mindíg ugyanaz fog történni (idempotens) 1. ábra Az egységes interfész legfontosabb műveletei Ha REST szolgáltatásokkal dolgozunk, akkor elegendő a fenti egységes interfészt megtanulnunk és alkalmaznunk. Web-szolgáltatás tervezéskor csak azt kell meghatároznunk, hogy egyes erőforrásokon mely műveleteket engedélyezzük, illetve web-szolgáltatások 12

13 felhasználásakor csak azt kell megvizsgálnunk, hogy mely műveletek támogatottak. Természetesen egy erőforrás létrehozásakor nem szükséges az egységes interfész minden verb-jét implementálnunk. Tehát a tervezési folyamat következő lépése az egységes interfész megvalósítása az erőforrásokon. A munkában nem korlátoz a REST, hiszen teljes mértékben a fejlesztőre van bízva, hogy milyen műveleteket engedélyez. Viszont figyelembe kell venni, hogy a webszolgáltatás a jövőben milyen környezetben fog futni, hiszen elképzelhető, hogy a webkiszolgálók, vagy védelmi vonalak úgy vannak bekonfigurálva, hogy a fenti interfészből csak pár műveletet támogassanak. Tipikusan a PUT és a DELETE áll a problémás kulcsszavak sorában. Kliensoldalon is lehetnek problémák. Korábban a böngészők sem támogatták a PUT és DELETE műveleteket, és ez a böngészőben futó kliensoldali alkalmazásoknál vethetett fel tervezési szintű kérdéseket. Például a Silverlight 2-ben még nem voltak támogatottak a szóban forgó műveletek [9]. A POST műveletet, ha lehetőség nyílik rá, a web-szolgáltatás fejlesztők elkerülik. Azok a REST stílusú web-szolgáltatások, amelyek csupán POST és GET műveleteket alkalmaznak, vagy még rosszabb esetben GET műveletek által módosítanak erőforrásokat, egyáltalán nem nevezhetők RESTful-nak. RESTful-ok azok a web-szolgáltatások, melyek az egységes interfészt tiszteletben tartva működnek A reprezentáció megtervezése A reprezentáció így definiálható; minden hasznos információ egy erőforrás állapotáról [10]. Mivel egy fizikai objektum nem adat, nem is feltételezhetjük, hogy az a weben elérhető. Viszont a meta-információik felhasználhatók az erőforrás reprezentációjaként. Kicsit pontosítva, ha egy erőforrás egy könyv, mint fizikai objektum, akkor annak reprezentációja lehet a meta-információja, például a borítójának egy fényképe, a könyv alapadatai, vagy maga a könyv digitális formában. Visszafele gondolkodva pedig, egy alkalmazásnak elküldhetünk meta-információkat is egy objektumról, amiből az alkalmazás erőforrást állít elő. Pontosan ez történik, amikor kitöltjük egy regisztrációs űrlapon a személyi adatainkat, amiből feltételezhetően egy bejegyzés születik a regisztrált ügyfeleket tartalmazó adatbázis táblában. Illetve meglévő erőforrásnak is készülhet új reprezentációja, például amikor egy fényképet küldünk el egy alkalmazásnak és az átkonvertálja, átméretezi, vízjellel látja el azt. 13

14 Az erőforrások megjelenése rendkívül változatos. Korábban a web-en média típusoknak (media types, HTTP fejlécekben Content-type) nevezték a szakemberek az erőforrások reprezentációit. Ha egy weboldalt tekintünk erőforrásnak, akkor a reprezentáció HTML vagy XHTML. Üzleti rendszerekben legtöbbször XML vagy manapság divatos JSON (JavaScript Object Notation) a használt. Továbbá a hírforrásoknál az RSS és az Atom a leggyakoribb. Természetesen egyéb erőforrások, mint például az audio-video erőforrások, képek, ikonok a saját, legtöbbször formátum-specifikus reprezentációval rendelkeznek. De a reprezentáció nem csak média típusokra terjed ki. Egy szöveges dokumentum reprezentációja lehet a nyelvi kultúra, amiben olvasható. Vagy épp egy termék ára, mely értékének szöveges formátuma illetve pénzneme is a reprezentációtól függhet. A REST lehetőséget ad arra, hogy egy erőforrásnak több reprezentációja is lehessen. Célszerű a reprezentációt az erőforrás URI-jében alkalmazni: (A 223-as rendelés XML alakban) (A 223-as rendelés JSON alakban) (A 223-as rendelés XHTML alakban) A nyelvi kultúrák esetén például: (A 101-es dokumentum magyarul) (A 101-es dokumentum angolul) A tervezési folyamat újabb és legtöbb esetben befejező lépése az erőforrásaink reprezentációinak meghatározása. Teljes mértékben szabad keze van a fejlesztőknek a formátumok kiválasztásában. Viszont egy erőforrás elérésekor a kívánt reprezentáció megadása több féle módon is történhet. A leginkább javasolt megoldás, hogy ami csak lehet, kerüljön bele az URL-be. Ellenben használhatók a HTTP kérés fejlécek is. Ez utóbbi hasznos lehet a kívánt nyelvi kultúra meghatározáskor, a böngészők az Accept-Language fejlécet használják erre. Mindkét megoldás RESTful [11]. Figyelembe kell venni, hogy a web-szolgáltatást gyakran más rendszerek fogják felhasználni. Így a megfelelő reprezentáció létkérdés. Továbbá kényes probléma, ha a reprezentáció megváltozik, miközben a szolgáltatást más rendszerek használják. Gyakorlati példa, ha egy rendelés XML reprezentációja szerkezetileg átalakul, és a kliens rendszerek erről nem értesülnek. 14

15 Kapcsolatok kialakítása A web talán legfontosabb tulajdonsága a linkelhetőség. Azaz hyperlink-ek segítségével kapcsolatok létesítése az erőforrások között. Egyik erőforrásról a másikra navigálhatunk, anélkül, hogy gondolkoznunk kellene a kívánt erőforrás URI-jén. Továbbá így lehet az állapot nélküliségnek állapotot adni. Gondolva például egy találati lista lapozhatóságára, ahol az oldalszámok hiperhivatkozások, így tudjuk, hogy hányadik oldalon vagyunk. Egy üzleti rendszerben rendkívül előnyös, ha egy XML reprezentációjú rendelési tételből le tudja tölteni a kliensalkalmazás a megrendelt terméket, esetleg a megrendelő adatait, mint erőforrásokat. Ehhez az kell, hogy a link-eknek megfelelő formában az erőforrásban kell szerepelniük. A tervezési folyamat utolsó lépése az erőforrások közötti kapcsolatok felépítése linkek segítségével. Ez nem egyszerű dolog, mivel a link-ek reprezentációfüggők. Egy JSON formátumú erőforrásban nem néz ki szépen XML formátumú erőforrásra mutató link. Vagy ha mégis megengedünk ilyet, akkor tájékoztatni kell a klienseket arról, hogy milyen reprezentációjú erőforrásra mutat egy-egy link. Továbbá a kliensalkalmazások gyakran rákeresnek az erőforrásokban a linkekre, így gondoskodni kell a link-ek egységes megjelenéséről. Vannak erőforrások, amikbe nem lehet linkeket helyezni, tipikusan ilyenek a bináris adatok. Ekkor válaszfejlécek használata javasolt. [12] 2.5. Tervezési minták, speciális megoldások Az évek során a tervezési folyamat minden lépéséhez kialakultak frappáns tervezési minták, melyeket célszerű ismernie a fejlesztőnek, ha RESTful szolgáltatásokat készít. Dolgozatomban is néhány alkalommal alkalmazok ilyen trükköket Tervezési minták erőforrásokhoz Léteznek tervezési mintákból eredő erőforrás típusok. Ilyenek például a kompozit (composites) erőforrások, melyek több erőforrás együttesét jelentik. Legyen egy weblap a 15

16 kompozit erőforrás, ahol legtöbbször több kisebb erőforrás szerepel egy helyen. Mint amikor egy ügyfél adatlapján meg tudjuk tekinteni annak kapcsolattartóit, korábbi megrendeléseit. Ezzel a megoldással gyorsíthatjuk az adatátvitelt, hiszen nem kell minden szükséges erőforrást egyenként lekérdeznünk [13]. A vezérlő erőforrások (controller resources) hosszabb, összetettebb szerveroldali műveletekhez használjuk, melyek legtöbbször több erőforrást is manipulálnak. Ilyen megoldást használnak, amikor egy telefonban lévő partnerlistát szinkronizálnak a szerveren lévő partnerekkel. Nem kell le- majd feltöltögetni a szerveren lévő partnereket, továbbá szükségtelen üzleti logikát tervezni a szinkronizáláshoz a kliensen. Egyszerűen feltöltjük a telefonban lévő partnerlistát a szerverre, mint controller erőforrás és a szerver elvégzi a dolgát. Ezzel nagyobb teljesítményre teszünk szert, kevésbé terheljük a hálózatot, nem kell szinkronizáló üzleti logikát létrehozniuk a kliensek fejlesztőinek és talán eredményt is kapunk a szinkronizálás hatásairól [14]. A tranzakciók is támogatottak a HTTP-n. Például, amikor egy banki tranzakcióról van szó, ahol az egyik számláról kell egy másikra utalni. A tranzakciót kezelhetjük erőforrásként, mint banki átutalás tranzakció, létrehozhatjuk (POST, PUT), vagy akár törölhetjük (DELETE). Egy hosszabb lefolyású tranzakciót, mint egy helyfoglalást a repülőn szintén így kezelhetünk [15]. 16

17 3. A WCF RESTful programozási modellje A WCF kliensoldalon és szerveroldalon is segíti a fejlesztők munkáját, szolgáltatások egyszerű létrehozásában és azok vagy épp más rendszerek szolgáltatásainak felhasználásában is. A SOAP szolgáltatások mellett a REST szolgáltatások létrehozását is bőkezűen támogatja. A fejezetben a WCF web programozási modellre koncentrálok, melyet legtöbbször WebHttp-nek, WebHttp Services-nek neveznek. Továbbá csak a szerveroldali viselkedést mutatom be WCF a szerveroldalon A WCF feladata szerveroldalon, hogy lefülelje a hálózaton át érkező üzeneteket és azokat feldolgozva továbbítsa a szolgáltatás kódjához, a fejlesztő implementációjához. Illetve üzenetet küldjön ki a hálózatra. Üzenet Hálózat Diszpécser 2. ábra A WCF szerveroldali csatorna verme Amikor megnyílik egy WCF szerveroldali végpont, a WCF csatornafigyelő (channel listener) segítségével létrehoz egy hálózat figyelőt, un. átviteli csatornát. A csatornafigyelő valójában egy gyár objektum, ami azért felelős, hogy előállítsa a szerveroldali figyelő infrastruktúrát. 17

18 Az üzenetértelmező a hálózati üzenetet átalakítja a WCF számára értelmezhető üzenetté. Ez az üzenet System.ServiceModel.Channels.Message típusú, melyből komplex.net objektumokat is vissza lehet állítani. A protokoll csatornák opcionálisak a modellben. Ezek segítségével lehet bizonyos stílusú architektúrákat implementálni. Fontosak lehetnek továbbá a nagy biztonságú és nagy megbízhatóságú szolgáltatások készítésekor. A diszpécser a beérkező üzenetek számára megfelelő metódusokat hívja meg. Ezek a metódusok már a fejlesztők kódját tartalmazzák. Először megvizsgálja, hogy melyik metódus a megfelelő, majd az üzenetet visszaállítja a kívánt.net típussá, és meghívja a metódust a szolgáltatást. Ezek együttesen alkotják a csatorna vermet, mely létrehozásához a WCF kötéseket (bindings) használ. A kötések konfiguráció beállítások, melyek konfigurációs file-ban vagy a memóriában, objektumként is elhelyezkedhetnek. Leggyakrabban a konfigurációs file-ban tartjuk nyílván ezeket, de.net 4 óta már erre sincs szükség, deklaratív programozásra is van lehetőség. Természetesen manuális kódolással is elő lehet állítani a csatorna vermet, a fenti komponensekkel. Két generációval ezelőtt a WCF 3.0-ban csak erre volt lehetőség [16] A WebHttp szolgáltatások A System.ServiceModel.Web.dll szerelvény a 3.5-ös.NET óta segíti a fejlesztőket. Ez tartalmazza a WebHttp, és így a REST szolgáltatások létrehozásához szükséges komponenseket. A System.ServiceModel és a System.ServiceModel.Web névterek a lényegesek. Néhány fontosabb komponens: WebHttpBinding ez a kötés a HTTP(S) átviteli csatornát és az üzenet értelmezőt (TextMessageEncoder) állítja be. WebHttpBehavior ez állítja be a WCF diszpécser rétegét, hogy a REST kéréseket a megfelelő szolgáltatás CLR metódusához irányítsa routing. Továbbá ez konfigurálja be a sorosító/visszaállító réteget. WebOperationContext ennek a környezeti komponensnek a WebOperationContext típusú, osztályszintű Current nevű tulajdonságával lehet elérni a kérelmek és válaszok minden részletét. Ez rendkívül fontos objektum, például ha HTTP kérésekből szeretnénk adatokat kinyerni, mint a HTTP fejlécek. 18

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül

Részletesebben

1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11

1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11 Tartalomjegyzék 1. fejezet Bevezetés a web programozásába (Balássy György munkája)... 11 Az internet működése... 11 Géptől gépig... 11 Számok a gépeknek... 13 Nevek az embereknek... 14 Programok egymás

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2 QBE Édes Otthon lakásbiztosítás tarifáló webservice Fejlesztői dokumentáció 1.0.2 Az ebben a dokumentumban található információ a FoxArt Kft. tulajdona, és bizalmas anyagként került átadásra. Az anyag

Részletesebben

Webes alkalmazások fejlesztése 8. előadás. Webszolgáltatások megvalósítása (ASP.NET WebAPI)

Webes alkalmazások fejlesztése 8. előadás. Webszolgáltatások megvalósítása (ASP.NET WebAPI) Eötvös Loránd Tudományegyetem Informatikai Kar Webes alkalmazások fejlesztése 8. előadás (ASP.NET WebAPI) 2016 Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A webszolgáltatás

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Gyakorlati vizsgatevékenység A

Gyakorlati vizsgatevékenység A Gyakorlati vizsgatevékenység A Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

Az alábbi kód egy JSON objektumot definiál, amiből az adtokat JavaScript segítségével a weboldal tartalmába ágyazzuk.

Az alábbi kód egy JSON objektumot definiál, amiből az adtokat JavaScript segítségével a weboldal tartalmába ágyazzuk. JSON tutorial Készítette: Cyber Zero Web: www.cyberzero.tk E-mail: cyberzero@freemail.hu Msn: cyberzero@mailpont.hu Skype: cyberzero_cz Fb: https://www.facebook.com/cyberzero.cz BEVEZETÉS: A JSON (JavaScript

Részletesebben

George Shepherd. 1. A webes alkalmazások alapjai 1

George Shepherd. 1. A webes alkalmazások alapjai 1 George Shepherd Köszönetnyilvánítás Bevezetés Az ASP.NET 2.0 fejlesztése A klasszikus ASP ASP.NET 1.0 és 1.1 ASP.NET 2.0 Néhány szó a.net-futtatórendszerről A könyv használatáról Kinek szól a könyv? A

Részletesebben

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal. Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 13. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. december A C++ programozási nyelv Soós Sándor 1/10 Tartalomjegyzék Objektumok

Részletesebben

Földmérési és Távérzékelési Intézet

Földmérési és Távérzékelési Intézet Ta p a s z ta l a to k é s g ya ko r l a t i m e g o l d á s o k a W M S s zo l gá l tatá s b a n Földmérési és Távérzékelési Intézet 2011.03.13. WMS Szolgáltatások célja A technikai fejlődéshez igazodva

Részletesebben

Nyilvántartási Rendszer

Nyilvántartási Rendszer Nyilvántartási Rendszer Veszprém Megyei Levéltár 2011.04.14. Készítette: Juszt Miklós Honnan indultunk? Rövid történeti áttekintés 2003 2007 2008-2011 Access alapú raktári topográfia Adatbázis optimalizálás,

Részletesebben

Elektronikus levelek. Az informatikai biztonság alapjai II.

Elektronikus levelek. Az informatikai biztonság alapjai II. Elektronikus levelek Az informatikai biztonság alapjai II. Készítette: Póserné Oláh Valéria poserne.valeria@nik.bmf.hu Miről lesz szó? Elektronikus levelek felépítése egyszerű szövegű levél felépítése

Részletesebben

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez A dokumentum célja A dokumentum

Részletesebben

Bevezetés Működési elv AJAX keretrendszerek AJAX

Bevezetés Működési elv AJAX keretrendszerek AJAX AJAX Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek Áttekintés Bevezetés Működési elv AJAX-ot támogató keretrendszerek

Részletesebben

NETinv. Új generációs informatikai és kommunikációs megoldások

NETinv. Új generációs informatikai és kommunikációs megoldások Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok

Részletesebben

TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS

TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS Hartung István BME Irányítástechnika és Informatika Tanszék TEMATIKA Cloud definíció, típusok, megvalósítási modellek Rövid Azure cloud bemutatás

Részletesebben

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2 Bevezetés xv Mitől tartozik egy platform a következő generációhoz?... xvi Mennyire jelentős az egyre újabb.net-változatok közötti különbség?... xviii Mit jelentett a Windows Vista megjelenése a Microsoft.NET

Részletesebben

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

Példa webáruház kialakítás rendszerdokumentáció

Példa webáruház kialakítás rendszerdokumentáció Példa webáruház kialakítás rendszerdokumentáció DWAM Webáruház integrációja meglévő belső ERP rendszerhez. A webáruház valamennyi termékkel és megrendeléssel összefüggő adatát a belső rendszer (..) tárolja,

Részletesebben

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg.

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. KIINDULÁS Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. Programozás III Az egyszerűség kedvéért mindegyiket a nevük alapján regisztráljuk,

Részletesebben

2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése

2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése Tartalom Integrált fejlesztés Java platformon JUnit JUnit használata Tesztelési technikák Demo 2 A specifikáció alapján teszteljük a program egyes részeit, klasszikus V-modell szerint Minden olyan metódust,

Részletesebben

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények 1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie

Részletesebben

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31 IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

TERC V.I.P. hardverkulcs regisztráció

TERC V.I.P. hardverkulcs regisztráció TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni

Részletesebben

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 a TávTagTár programhoz Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 Tartalomjegyzék Futási feltételek... 3 Telepítés... 3 Indítás... 3 Főablak... 4 Új személy felvétele...

Részletesebben

Gyakorlati vizsgatevékenység B

Gyakorlati vizsgatevékenység B Gyakorlati vizsgatevékenység Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

Verifikáció és validáció Általános bevezető

Verifikáció és validáció Általános bevezető Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának

Részletesebben

RBLDNS DNS-based blocklists management felhasználói kézikönyv

RBLDNS DNS-based blocklists management felhasználói kézikönyv RBLDNS DNS-based blocklists management felhasználói kézikönyv (INTEGRITY Kft. 2013. 12. 9.) Bevezető ismertetés Az RBLDNS rendszer a hagyományos DNS protokollra épülő rendszer, melyet elsősorban black

Részletesebben

Oralce kliens installálása Windows Server 2003-ra

Oralce kliens installálása Windows Server 2003-ra Oralce kliens installálása Windows Server 2003-ra Szükséges elofeltétel Szükséges operációs rendszer: Windows 2003 SP1 Oracle kliens verzió: 9.2.0.1.0 (9R2) Valid SQLNet.ORA fájl, amely tartalmazza a céges

Részletesebben

RBLDNS DNS-based blocklists management felhasználói kézikönyv

RBLDNS DNS-based blocklists management felhasználói kézikönyv RBLDNS DNS-based blocklists management felhasználói kézikönyv (INTEGRITY Kft. 2013. 06. 27.) RBLDNS Webes kezelőfelülete Az INTEGRITY által működtetett RBLDNS rendszer webes felületét a spamdns.eu/rbl/

Részletesebben

Szoftver Tervezési Dokumentáció. Nguyen Thai Binh

Szoftver Tervezési Dokumentáció. Nguyen Thai Binh Szoftver Tervezési Dokumentáció Nguyen Thai Binh April 2010 1. fejezet Feladat Szimulációs feladat. Célja, hogy reprezentáljunk egy több komponensből álló alkalmazást, amely a megadott témakörnek megfelel,

Részletesebben

Zimbra levelező rendszer

Zimbra levelező rendszer Zimbra levelező rendszer Budapest, 2011. január 11. Tartalomjegyzék Tartalomjegyzék... 2 Dokumentum információ... 3 Változások... 3 Bevezetés... 4 Funkciók... 5 Email... 5 Társalgás, nézetek, és keresés...

Részletesebben

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1]

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] T a r t a l o m j e g y z é k 1 Bevezetés... 3 1.1 A rendszer rövid leírása... 3 1.2 A dokumentum célja... 3 1.3 A rendszer komponensei... 3 1.4

Részletesebben

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Mi az IMDG? Nem memóriában futó relációs adatbázis NoSQL hagyományos relációs adatbázis Más fajta adat tárolás Az összes adat RAM-ban van, osztott

Részletesebben

Országos Területrendezési Terv térképi mel ékleteinek WMS szolgáltatással történő elérése, Quantum GIS program alkalmazásával Útmutató 2010.

Országos Területrendezési Terv térképi mel ékleteinek WMS szolgáltatással történő elérése, Quantum GIS program alkalmazásával Útmutató 2010. Országos Területrendezési Terv térképi mellékleteinek WMS szolgáltatással történő elérése, Quantum GIS program alkalmazásával Útmutató 2010. május 1. BEVEZETÉS Az útmutató célja az Országos Területrendezési

Részletesebben

Szakdolgozati, TDK témajavaslatok

Szakdolgozati, TDK témajavaslatok Kiadta: IB Controll Kft. Összeállította: Nagy Imre Dokumentum verzió: v1.0 Utolsó frissítés dátuma: 2015. 03. 30. Tartalomjegyzék 1. Bevezetés...3 2. Témajavaslatok...4 2.1.1. OpenWrt / Linux szerver admin

Részletesebben

Web-fejlesztés NGM_IN002_1

Web-fejlesztés NGM_IN002_1 Web-fejlesztés NGM_IN002_1 Rich Internet Applications RIA Vékony-kliens generált (statikus) HTML megjelenítése szerver oldali feldolgozással szinkron oldal megjelenítéssel RIA desktop alkalmazások funkcionalitása

Részletesebben

Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt

Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt segédlet A Szilipet programok az adatok tárolásához Firebird adatbázis szervert használnak. Hálózatos

Részletesebben

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat.

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. Súgó Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. A lekérdező rendszer a Hírközlési Szolgáltatások és Interfész bejelentések, valamint az

Részletesebben

SOAP komponensek Delphiben

SOAP komponensek Delphiben SOAP komponensek Delphiben (Simple Object Access Protocol) Bevezetés -Azegyszerűen programozható webhozzáférés azt jelenti, hogy a fejlesztők saját programjukat a weben elérhető szolgáltatásokból építik

Részletesebben

WWW Kliens-szerver Alapfogalmak Technológiák Terv. Web programozás 1 / 31

WWW Kliens-szerver Alapfogalmak Technológiák Terv. Web programozás 1 / 31 Web programozás 2011 2012 1 / 31 Áttekintés Mi a web? / A web rövid története Kliens szerver architektúra Néhány alapfogalom Kliens- illetve szerver oldali technológiák áttekintése Miről lesz szó... (kurzus/labor/vizsga)

Részletesebben

EgroupWare: A csoportmunka megoldás

EgroupWare: A csoportmunka megoldás EgroupWare: A csoportmunka megoldás Bemutatás Az egroupware egy üzleti szintű, PHP alapú, szabad csoportmunka szerver megoldás, a Stylite AG terméke. A közösségi verzió szabadon letölthető és ingyenesen

Részletesebben

Telenor Magyarország MS Office 365 telepítési útmutató

Telenor Magyarország MS Office 365 telepítési útmutató Telenor Magyarország MS Office 365 telepítési útmutató Tartalomjegyzék 1 MEGJEGYZÉS a.hu domainnel regisztrált ÜGYFELEK számára... 2 2 Bejelentkezés az O365 fiókba... 3 2.1 Az adminisztrátor felhasználói

Részletesebben

BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv?

BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv? BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv? Készítették: Névery Tibor és Széll Ildikó PPKE I. évf. kiadói szerkesztő hallgatók, közösen 1 BEVEZETŐ Az elektronikus könyv valamilyen

Részletesebben

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció H - 1161 Budapest Rákóczi út 76. Tel./Fax.: +36-1-4010159 http://www.pageos.hu toni@pageos.hu DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció A program használható a TOPOBASE

Részletesebben

Internet programozása. 1. előadás

Internet programozása. 1. előadás Internet programozása 1. előadás Áttekintés 1. Mi a PHP? 2. A PHP fejlődése 3. A PHP 4 újdonságai 4. Miért pont PHP? 5. A programfejlesztés eszközei 1. Mi a PHP? Egy makrókészlet volt, amely személyes

Részletesebben

Kalumet Számlázó. Termék leírás

Kalumet Számlázó. Termék leírás Kalumet Számlázó Termék leírás Rendszerünk potenciális felhasználói Olyan vállalkozások, akiknél fontos cél, szempont, ügyfeleik kiemelt szintű kiszolgálása. Akik szeretnék, hogy a tevékenységeik, ügyfél

Részletesebben

OOP és UML Áttekintés

OOP és UML Áttekintés OOP és UML Áttekintés Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) OOP és UML Áttekintés 2013 1 / 32 Tartalom jegyzék 1 OOP Osztály Öröklődés Interfész, Absztrakt Osztály Kivétel kezelés

Részletesebben

Podoski Péter és Zabb László

Podoski Péter és Zabb László Podoski Péter és Zabb László Bevezető Algoritmus-vizualizáció témakörében végeztünk kutatásokat és fejlesztéseket Felmértük a manapság ismert eszközök előnyeit és hiányosságait Kidolgoztunk egy saját megjelenítő

Részletesebben

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb. SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.hu Mesterséges intelligencia oktatás a DE Informatikai

Részletesebben

Cikktípusok készítése a Xarayában

Cikktípusok készítése a Xarayában Cikktípusok készítése a Xarayában A Xaraya legfontosabb tulajdonsága az egyedi cikktípusok egyszerű készítésének lehetősége. Ezzel kiküszöbölhető egyedi modulok készítése, hiszen néhány kattintással tetszőleges

Részletesebben

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport TANMENET Informatika szakmacsoport Programozási gyakorlatok III. tantárgy 12. évfolyam A osztály 2013/2014 tanév Heti óraszám: Éves óraszám: 3 óra 96 óra Készítette: Szikszai Gusztáv tanár Ellenőrizte:.

Részletesebben

Adatbázis rendszerek 6.. 6. 1.1. Definíciók:

Adatbázis rendszerek 6.. 6. 1.1. Definíciók: Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A

Részletesebben

Flex: csak rugalmasan!

Flex: csak rugalmasan! Flex: csak rugalmasan! Kiss-Tóth Marcell http://kiss-toth.hu marcell@kiss-toth.hu Magyarországi Web Konferencia 2006 2006. március 18. tartalom bevezető Adobe Flex alternatív technológiák bevezető az Internetnek

Részletesebben

Web programoz as 2009 2010

Web programoz as 2009 2010 Web programozás 2009 2010 Áttekintés A web rövid története Kliens szerver architektúra Néhány alapfogalom Kliens- illetve szerver oldali technológiák áttekintése Áttekintés: miről lesz szó (kurzus/labor/vizsga)

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 8. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. november A C++ programozási nyelv Soós Sándor 1/12 Tartalomjegyzék Miért

Részletesebben

I. rész: A Microsoft Visual C# és a Microsoft Visual Studio 2005 bemutatása. 1. Üdvözöljük a C# világában! 3

I. rész: A Microsoft Visual C# és a Microsoft Visual Studio 2005 bemutatása. 1. Üdvözöljük a C# világában! 3 Köszönetnyilvánítás Bevezetés Honnan kezdjük a könyv olvasását? A könyvben használt konvenciók és egyéb jelölések Konvenciók Egyéb jelölések Online kiegészítő tartalom Technológiai frissítések Rendszerkövetelmények

Részletesebben

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Educatio Társadalmi Szolgáltató Nonprofit kft. FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Felhasználói kézikönyv Dokumentum állapota: Tervezet Verzió: 0.1.0 Tartalomjegyzék 1. Bevezetés... 3 2. Bejelentkezés...

Részletesebben

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Telepítés internetről A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Új szolgáltatásunk keretén belül, olyan lehetőséget kínálunk a TERC VIP költségvetéskészítő program

Részletesebben

ALKALMAZÁS KERETRENDSZER

ALKALMAZÁS KERETRENDSZER JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak

Részletesebben

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás Petőfi Irodalmi Múzeum A Digitális Irodalmi Akadémia megújuló rendszere technológiaváltás II. Partnerek, feladatok Petőfi Irodalmi Múzeum Megrendelő, szakmai vezetés, kontroll Konzorcium MTA SZTAKI Internet

Részletesebben

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás

Részletesebben

Kezdő lépések Microsoft Outlook

Kezdő lépések Microsoft Outlook Kezdő lépések Microsoft Outlook A Central Europe On-Demand Zrt. által, a Telenor Magyarország Zrt. részére nyújtott szolgáltatások rövid kezelési útmutatója 1 Tartalom Áttekintés... 3 MAPI mailbox konfiguráció

Részletesebben

Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok

Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok Informix 11.50 upgrade esettanulmány 2011. január. 31. Átalakítandó architektúra (2009) Alapvetően az üzleti logikát tárolt eljárásokkal

Részletesebben

Alapok (a K2D rendszer alapjai)

Alapok (a K2D rendszer alapjai) Alapok (a K2D rendszer alapjai) 1 1. Bevezetés... 3 2. Fastruktúra... 3 2.1. Nyitása, zárása... 3 2.2. Fülek... 5 2.3. Licence kulcs érvényesítése... 9 2.4. Új elem felvitele... 10 2.5. Elem törlése...

Részletesebben

Adatbázis, adatbázis-kezelő

Adatbázis, adatbázis-kezelő Adatbázisok I. rész Adatbázis, adatbázis-kezelő Adatbázis: Nagy adathalmaz Közvetlenül elérhető háttértárolón (pl. merevlemez) Jól szervezett Osztott Adatbázis-kezelő szoftver hozzáadás, lekérdezés, módosítás,

Részletesebben

SABLONOZÓ KERETRENDSZER

SABLONOZÓ KERETRENDSZER SABRE SABLONOZÓ KERETRENDSZER 2014 1 FELHASZNÁLÓK Számtalan olyan vállalat és állami szervezet létezik, akik ügyfeleikkel sablonlevelek segítségével kommunikálnak, vagy sablonlevelekben értesítik partnereiket

Részletesebben

Mai program. Web Technológiák. Webalkalmazások. Webalkalmazás, mint UI

Mai program. Web Technológiák. Webalkalmazások. Webalkalmazás, mint UI Web Technológiák Mai program Répási Tibor egyetemi tanársegéd Miskolc Egyetem Infomatikai és Villamosmérnöki Tanszékcsoport (IVM) Általános Informatikai Tanszék Iroda: Inf.Int. 108. Tel: 2101 Webalkalmazás

Részletesebben

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja.

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A hálózat kettő vagy több egymással összekapcsolt számítógép, amelyek között adatforgalom

Részletesebben

PortaWin (PW2) Jármű mérlegelő program Mérlegelés több cég számára

PortaWin (PW2) Jármű mérlegelő program Mérlegelés több cég számára METRISoft Mérleggyártó KFT PortaWin (PW2) Jármű mérlegelő program 6800 Hódmezővásárhely Jókai u. 30 Telefon: (62) 246-657, Fax: (62) 249-765 e-mail: merleg@metrisoft.hu Web: http://www.metrisoft.hu Módosítva:

Részletesebben

Digitális írástudás kompetenciák: IT alpismeretek

Digitális írástudás kompetenciák: IT alpismeretek Digitális írástudás kompetenciák: IT alpismeretek PL-5107 A továbbképzés célja: A program az alapvető számítógépes fogalmakban való jártasságot és a számítógépek alkalmazási területeinek ismeretét nyújtja

Részletesebben

Kedvenc Linkek a témakörben: MySQL mindenkinek Vizuális adatbázis tervezés

Kedvenc Linkek a témakörben: MySQL mindenkinek Vizuális adatbázis tervezés Nagyon fontos, hogy az adatbázis tervezések folyamán is, ugyan úgy mint a megvalósítandó programhoz, legyenek modelljeink, dokumentációk, diagramok, képek, stb.., ezek segítségével könnyebben átlátjuk

Részletesebben

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel A piacon lévő ügyviteli szoftverek jó részének legnagyobb hibája, hogy a letárolt adatokat nem képesek a felhasználó által hasznosítható

Részletesebben

PRECÍZ Információs füzetek

PRECÍZ Információs füzetek PRECÍZ Információs füzetek Információk, Módszerek, Ötletek és Megoldások a Precíz Integrált Ügyviteli Információs rendszerhez 3. EXCEL adatkapcsolat (mod. 2009.07.) Ügyviteli nyilvántartások és EXCEL formátumú

Részletesebben

MŰSZAKI DOKUMENTÁCIÓ. Aleph WebOPAC elérhetővé tétele okostelefonon. Eötvös József Főiskola 6500 Baja, Szegedi út 2.

MŰSZAKI DOKUMENTÁCIÓ. Aleph WebOPAC elérhetővé tétele okostelefonon. Eötvös József Főiskola 6500 Baja, Szegedi út 2. Telefon: Fax: E-mail: (+36-1) 269-1642 (+36-1) 331 8479 info@ex-lh.hu www.ex-lh.hu Eötvös József Főiskola 6500 Baja, Szegedi út 2. MŰSZAKI DOKUMENTÁCIÓ Aleph WebOPAC elérhetővé tétele okostelefonon Pályázati

Részletesebben

NEPTUN ID BMENET ID. Címtár BME VPN. vcenter VPN SVN. Trac Wiki. Wifi

NEPTUN ID BMENET ID. Címtár BME VPN. vcenter VPN SVN. Trac Wiki. Wifi Tanszék N NEPTUN ID Címtár vcenter Trac Wiki SVN Wifi VPN BMENET ID BME VPN BME címtár elérés Drupal alól Ujhelyi Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek

Részletesebben

ECP. Site Administration System. Felhasználói kézikönyv. v2.9.24+ (1. kiadás a 2.9.24 és újabb verziójú ECP SAS rendszerekhez)

ECP. Site Administration System. Felhasználói kézikönyv. v2.9.24+ (1. kiadás a 2.9.24 és újabb verziójú ECP SAS rendszerekhez) v2.9.24+ ECP Site Administration System Felhasználói kézikönyv (1. kiadás a 2.9.24 és újabb verziójú ECP SAS rendszerekhez) AW STUDIO Nyíregyháza, Luther utca 5. 1/5, info@awstudio.hu 1 2 Jelen dokumentáció

Részletesebben

ContractTray program Leírás

ContractTray program Leírás ContractTray program Leírás Budapest 2015 Bevezetés Egy-egy szerződéshez tartozó határidő elmulasztásának komoly gazdasági következménye lehet. Éppen ezért a Szerződés kezelő program főmenü ablakában a

Részletesebben

ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA

ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA Készítette: Hunet Kft, 2013 Ez az alkotás a Creative Commons Nevezd meg! - Ne add el! - Így add tovább! 2.5 Magyarország licenc alá tartozik. A licenc megtekintéséhez

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1

XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1 XML Webszolgáltatás alapú osztott alkalmazás fejlesztése Johanyák Zsolt Csaba 1 A gyakorlat célja a webszolgáltatások létrehozásának és igénybe vételének elsajátítása egyszerű példákon keresztül. 1. Két

Részletesebben

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val)

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) A leolvasási feladat AS Szerver DB Számlázási, ügyfélszolgálati adatbázis Adatgyűjtő szerver Mobil adatgyűjtő AS szerver

Részletesebben

vbar (Vemsoft banki BAR rendszer)

vbar (Vemsoft banki BAR rendszer) vbar (Vemsoft banki BAR rendszer) BAR bemutatása 1994. július 1-jétől kezdte meg működését a Központi Adós- és Hitelinformációs Rendszer, azóta is használt rövidített nevén a BAR, amely kezdetben kizárólag

Részletesebben

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT Fertői Ferenc 2010 Szegedi Tudományegyetem Informatikai Tanszékcsoport 3-dimenziós táj generálása útvonalgráf alapján Szakdolgozat Készítette:

Részletesebben

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel A jövő üzleti telefon rendszere A jövő vállalati telefon rendszerének 4 alappillére SMS Mobil mellékek Webtelefon Üzenetküldés Összhang az IT-vel É rdemes elolvasni! Ajánlatkérés Kérem, töltse ki az űrlapot,

Részletesebben

Mérlegelés több cég számára

Mérlegelés több cég számára METRISoft Mérleggyártó KFT PortaWin (PW2) Jármű mérlegelő program 6800 Hódmezővásárhely Jókai u. 30 Telefon: (62) 246-657, Fax: (62) 249-765 e-mail: merleg@metrisoft.hu Web: http://www.metrisoft.hu Módosítva:

Részletesebben

OZEKI Phone System. 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára. A jövő üzleti telefon rendszere SMS

OZEKI Phone System. 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára. A jövő üzleti telefon rendszere SMS A jövő üzleti telefon rendszere 4 elengedhetetlen szolgáltatás a jövőbeli vállalati telefonos rendszerek számára SMS Mobil mellékek Webtelefon Üzenetküldés és jelenlét Összhang az IT-vel Olvassa el! Ajánlatkérő

Részletesebben

Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás?

Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás? Bevezetés Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések Forráskód Hibajegyzék p2p.wrox.com xiii xiii xiv xiv xvi xvii xviii

Részletesebben

Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül

Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül Letöltési Procedúra Fontos: Ha Ön tűzfalon vagy proxy szerveren keresztül dolgozik akkor a letöltés előtt nézze meg a Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül

Részletesebben

Iman 3.0 szoftverdokumentáció

Iman 3.0 szoftverdokumentáció Melléklet: Az iman3 program előzetes leírása. Iman 3.0 szoftverdokumentáció Tartalomjegyzék 1. Az Iman rendszer...2 1.1. Modulok...2 1.2. Modulok részletes leírása...2 1.2.1. Iman.exe...2 1.2.2. Interpreter.dll...3

Részletesebben

Telepítési Kézikönyv

Telepítési Kézikönyv Intelligens Dokumentum Kezelő Rendszer Telepítési Kézikönyv 1/15. oldal Dokumentum áttekintés Dokumentum címe: doknet telepítési kézikönyv Dokumentum besorolása: szoftver telepítési leírás Projektszám:

Részletesebben

ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL

ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL ELEKTRONIKUS MUNKABÉRJEGYZÉK MODUL nexonbér elektronikus munkabérjegyzék modul Kiszámolta már valaha, hogy mennyibe kerül egyetlen munkavállaló egyetlen havi munkabérjegyzéke (a nyomtatás, a borítékolás

Részletesebben

Erőforrás gazdálkodás a bevetésirányításban

Erőforrás gazdálkodás a bevetésirányításban Professzionális Mobiltávközlési Nap 2009 Új utakon az EDR Erőforrás gazdálkodás a bevetésirányításban Fornax ZRt. Nagy Zoltán Vezérigazgató helyettes Budapest, 2009. április 9. Tartalom 1. Kézzelfogható

Részletesebben

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés

Részletesebben

Gyakorlati vizsgatevékenység B

Gyakorlati vizsgatevékenység B 55 41 04 0000 00 00 Web-programozó 110-06 111-06 70-06 11-06 119-06 1.. 3. 1.. 1.. 3. 1.. 1.. 3. 4. 5. Gyakorlati vizsgatevékenység B Szakképesítés azonosító száma, megnevezése: 55 41 04 0000 00 00 Web-programozó

Részletesebben