Symbol eXtension » Fejlesztési kisokos

“Fejlesztési kisokos” bejegyzések.

Munkafolyamat kezelés (session) webmetódusok esetén

posted in: SaaS és Intranet (Tags: , , ) - No Comments

A webes kiszolgáló alkalmazások valamilyen módon kell, hogy kezeljenek munkafolyamatokat. Az alábbi tipikus példák megvilágítják, miért kell munkaFOLYAMATOKban gondolkodni és miért jó a cookie-kra alapozott szerver oldali session kezelés.

  • A felhasználó egyszer lépjen be. Nyilvánvaló, hogy a felhasználó csak egyszer szeretne belépni a rendszerbe és nem szeretné magát azonosítani minden lépés elején vagy végén. Ilyen esetben a bejelentkezett felhasználó adatait szerver oldali session-be rakjuk el és ahol kell, tudjuk ellenőrizni/felhasználni.
  • Korábbi műveletek tárolása. A belépett felhasználó szeretné látni, hogy a munkafolyamat közben mit végzett el. Mivel tetszőleges adatokat tárolhatunk a session-ökben, korábban meglátogatott oldalak/funkció tárolására is lehetőség van.

A session kezelés a SyX SDK-ban memóriában valósul meg. A Symbol Ügyvitel vagy a SyX beépülő újraindítása minden session-t megszűntet. A session-ök a cookie-k lejárati idejétől függetlenül, az utolsó kattintás után maximum 30percig élnek.

 

Az alábbi módon használhatóak a session-ök és az abban tárolt változók.

A webmetódusok törzsében használhatjuk a Session változót, amely egy névvel indexelhető Dictionary. Használati módja a következő:

Session[“UserName”] = “SymbolDefaultUser”;
// a megadott string értéke eltárolásra kerül az UserName munkafolyamat változóban.

x = Session[“UserName”];
// az UserName munkafolyamat változó tartalmát érhetjük el.

 

A Session változó Strings tulajdonsága a munkafolyamat változókat nem Object típusként, hanem String típusként kezeli adatkonverzió nélkül.

Session.Strings[“UserName”] = “SymbolDefaultUser”;

string value = Session.Strings[“UserName”];


 

Webmetódusok – Tömörített adatküldés

posted in: SaaS és Intranet (Tags: , , , , , , ) - No Comments

Amennyiben a böngésző engedélyezi a tömörített adatok fogadását (gzip, deflate), úgy a SyX-ek a webmetódusok HTML eredményét tömörített formátumban adják vissza.

A Request Accept-Encoding értéke alapján (gzip, deflate) eldöntésre kerül, hogy a böngésző képes-e tömörített adatfolyam feldolgozására. Amennyiben képes, úgy a HTML tartalom GZIP tömörítve kerül kiküldésre. A fenti működés automatikus, semmilyen egyéb beállításra nincs szükség.

Ennek segítségével a mobil adatkapcsolatokon (GSM, EDGE, 3G) gyorsabb oldalbetöltődés érhető el.

A működés nem befolyásolja az XML alapú vagy elemi adattípusokkal való kommunikációt, csupán a HtmlResponse visszatérési értékű metódusokkal működik együtt.

Web kérések és forgalom naplózása

posted in: SaaS és Intranet (Tags: , , , ) - No Comments

Hibakeresési, tesztelése, optimalizálási célból előnyös, ha a webmethod-ok hívásait naplózni lehet. Erre a SyX SDK új verziója lehetőséget biztosít.

A WebLog attribútum beillesztése következtében a megadott fájlnevek alatt létrejön az elérési napló és a hibanapló. Ha valamely fájlt nem adjuk meg, akkor olyan típusú napló nem készül. Az elérési napló minden lekérdezést egy-egy sorban jelez, a hibanapló csak a 200-as HTTP választól eltérő eseményeket jelzi.

A naplózás gyakori művelet, egy oldal lekérésekor 3-10 naplóbejegyzés is készülhet. Emiatt a naplófájlokat csak helyi meghajtón szabad elhelyezni, nehogy a kiszolgálás teljesítménye csökkenjen!

Példa:

[WebLog(“c:\\weblog\\access.log”, “c:\\weblog\\error.log”)]

Az attribútum következtében a c:\weblog mappában készül el a két fájl.

Böngésző tulajdonságai

posted in: SaaS és Intranet (Tags: , , ) - No Comments

SaaS működés kiszolgálása közben felmerülhet az igény, hogy tudjuk, honnan érkezett a kérés, milyen böngészőben jelennek meg az adatok.

A kérdések megválaszolására létrehoztuk a SyX SDK-ban a GetRequestContext() metódust, amely egy RequestContext objektumot ad vissza. Ebben az objektumban megtalálható minden, ami a kéréssel kapcsolatos:

  • UserAgent
  • Kérés IP címe
  • Kérés HOST neve
  • Elfogadott nyelvek
  • Cookie információk

Ezen túl pedig egy beépített metódus (IsMobile) megállapítja, hogy mobil böngészőről van-e szó. Ilyen esetben kisebb tartalmat szoktak megjelenteni a portálok.

Csak webkiszolgáló üzemmód esetén használható a metódus, egyéb esetben NULL értéket ad vissza; webkiszolgáló működésnek minősül a desktop és a 365/24-es működés is!

Példa:

[WebMethod("Display User-Agent")]
public HtmlResponse UserAgent()
{
    RequestContext ctx = GetRequestContext();

    StringBuilder sb = new StringBuilder();
    if (ctx.IsMobile)
        sb.AppendLine("Mobile");
    sb.AppendLine(ThreadName);
    sb.AppendLine(String.Join(", ", ctx.Request.AcceptTypes));
    sb.AppendLine(ctx.Request.RequestTraceIdentifier.ToString());
    sb.AppendLine(ctx.Request.ServiceName);
    sb.AppendLine(ctx.Request.UserAgent);
    sb.AppendLine(ctx.Request.UserHostAddress);
    sb.AppendLine(ctx.Request.UserHostName);
    sb.AppendLine(String.Join(", ", ctx.Request.UserLanguages));

    return new HtmlResponse(sb.ToString());
}

Metódusok időzítése

posted in: Keretrendszer (Tags: , , , ) - No Comments

Egy keretrendszer folyamatosan fejlődik, ahogy az igények azt indokolják. Egyre gyakrabban merül fel, hogy időzítetten kell valamit futtatni. Legyen az adatok letöltése, információk exportálása vagy SMS küldése. Ennek kiszolgálására bővítettük a SyX SDK-t.

Minden paraméter nélküli metódus meghívható a

[CronScheduler(“*/2 9-17 * * 1,2,3,4,5”)]

attribútummal. Az attribútum paramétere egy Cron jellegű időzítési string. A beépített időzítő a Cron paraméternek megfelelő gyakorisággal futtatja a metódust. (http://en.wikipedia.org/wiki/Cron)

A példában szereplő string minden munkanapon (H-P) 9-17 óráig minden páros percben futtat valamit.

A Cron időzítés előnye, hogy nem kell nekünk saját Timer-t létrehozni, a rendszer ezt optimalizáltan megteszi helyettünk. Hátránya viszont, hogy csak állandó időzítési idejű metódusok hozhatóak létre, felhasználói beállítássá nem lehető az időzítés gyakorisága.

Megjegyzések:

  • A metódus továbbra is megjelölhető Modul függő opciókkal (pl.: csak gyártás modul esetén fusson)
  • A metódus továbbra is megjelölhető Permission attribútummal (csak megfelelő jogosultság esetén fut)
  • A metódust a hagyományos módon menüpontként vagy funkció gombként is használhatjuk. Megfordítva: meglévő metódust is elláthatunk CronScheduler attribútummal.

SyX jogosultságok

posted in: Keretrendszer (Tags: , , , , , ) - No Comments

Nagycéges környezetben gyakori, hogy a jogosultsági rendszerrel csak bizonyos menüpontokat engedünk elérni a felhasználóknak. Mostantól a SyX beépülők által létrehozott menüpontok, gombok, funkciók is jogosultsághoz köthetőek.

Ehhez a SyX készítőjének felül kell írnia a GetPermissionDescriptiors() metódust, amelyben int->string párokat létrehozva definiálhatja a jogosultságokat. Ezek a jogosultságok a felhasználói / csoport jogosultságok között megjelennek és felhasználónként megadhatóak / elvehetőek.

A [Permission(int perm)] attribútum felhasználásával pedig minden SyX funkcióhoz meg lehet adni, hogy milyen jog kell a végrehajtásához. Mit lehet védeni jogosultságokkal?

  • Teljes SyX védelme: Be sem tudja tölteni (hibaüzenettel jelenik meg) a SyX beépülőt az, aki egy teljesen védett SyX-hez nem kapott jogot.
  • Menüpontok: Az új menüpontok nem látszanak azoknál a felhasználóknál, akik nem kaptak jogot hozzá.
  • Műveleti gombok: Az új műveleti gombok nem látszanak azoknál a felhasználóknál, akik nem kaptak jogot hozzá.
  • WebMethod-ok: A SyX által létrehozott webszerver adott funkcióihoz a felhasználó nem férhet hozzá ha nincs joga. A funkciók listáján a funkció nem látszik, de az URL-t közvetlenül beírva is 404-es hibaüzenettel válaszol a szerver.

8. Statikus HTML elemek használata csomagban

posted in: SaaS és Intranet (Tags: , , , , ) - No Comments

A statikus HTML tartalom (js, css, kép fájlok) elhelyezése kis és közepes fájl mennyiség esetén nem okoz gondot. De egyre gyakoribb valamelyik JS függvénykönyvtár használata (prototype, dojo, jsScrolling, Sajax, jQuery, stb.). Ezek pedig általában több, mint 100 fájlt is tartalmazhatnak. Hagyományos webszerver esetén nincs más dolgunk, mint a ZIP állomány tartalmát kicsomagolni a web kiszolgáló egyik könyvtárába. Nézzük, hogy oldható meg egy SaaS-es SyX esetén!

Nagy mennyiségű statikus fájl kezelésére vezettük be a WebStaticResourcePack attribútumot. A WebStaticResource mintájára egy virtuális könyvtárat kell megadni, ahova fel kívánjuk fűzni (mount) a statikus fájlokat. Emellett a Resource típusát és a resource-ban elhelyezett ZIP fájl nevét kell megadnunk.

[WebStaticResourcePack(“jquery”, typeof(StatRes), “examples”)]

A fenti példa a jquery könyvtárban “helyezi el” a StatRes resource fájlunk examples.zip tartalmát. Például ha a böngésző vagy valamely JS script el akarja érni a http://srv.hu/jquery/styles/default/all.css fájlt, akkor a ZIP fájlban lévő /styles/default/all.css fájl kerül kiszolgálásra.

 

A fenti megoldás – a belső gyorsítótáraknak hála – 8-20ms-os válaszidővel működik, közvetlenül a memóriából szolgálja ki a kéréseket, a többszálas (thread) mechanizmust kihasználva. (A fenti idő vetekszik a célirányos Linux/IIS szerverek válaszidejével).

Fontos megjegyzeni, hogy a ZIP fájlban történt módosítás a SyX újrafordításával kerül érvényesítésre, amely 2-5mp.

 

Szálban fut, de ablakot jelenít meg…

posted in: Felhasználói felület, Keretrendszer (Tags: , , , ) - No Comments

A SyX beépülők több helyen használhatnak szálakat működésük közben. A fejlesztő használhat “kézzel” szálakat, de az SaaS működés minden esetben szálban kerül kiszolgálásra. Ritkán, de előfordulhat, hogy a szál valamilyen felhasználói felületet is működtet. Példa erre, ha egy HTTP kérés hatására egy új számla ablak jelenik meg, amin még módosításokat lehet végezni.

Ennek a több szálas problémának a megoldására vezettük be a keretrendszerben az alábbi metódust:

InvokeThreadSafe(MethodInvoker invoker)

Az InvokeThreadSafe hívás során átadott (MethodInvoker-be beburkolt) metódus a főszálon, szinkronizáltan kerül végrehajtásra. Például egy újonnan, szálban létrehozott számla megjelenítise az alábbi módon valósítható meg:

InvokeThreadSafe(new MethodInvoker(so.Display)) //so.Display() beépített metódusa minden Entity-nek.

7. Statikus HTML elemek használata

posted in: SaaS és Intranet (Tags: , , , , ) - No Comments

Az Intranet portálok mindegyike tartalmaz több statikus webes elemet. Ilyenek például a konstans képek (cornet.jpg) illetve a javascript függvénytárak (jQuery.js). Az Intranet portál kiszolgálója a Symbol Ügyvitel rendszer, így a böngészők számára ezeket a fájlokat is innen kell tudni kiszolgálni.

 

Hagyományos megoldás

A hagyományos megoldás az lenne, ha a fájlok mindegyikéhez létrehozunk egy megfelelő nevű metódust. Például a jQuery.js fájlhoz a jQuery_js() metódust kellene definiálni. A hagyományos megoldás az alábbi problémákat veti fel:

  • Nehézkesen bővíthető a fájlok listája
  • Elnevezési konvenciók szem előtt tartása problémát okozhat
  • Nem lehet alkönyvtárakban elhelyezni a fájlokat (/images/main.jpg, /js/jQuery.js)

 

Statikus erőforrás megoldás

A statikus fájlok elhelyezésének módja .NET Resource fájl(ok) létrehozása. Az ott tárolt fájlok kiszolgálását megkönnyítendő a rendszer tartalmazza a WebStaticResourceAttribute attrubútumot. Ennek használatával egy meglévő Resource fájlt felfűzhetünk a paraméterként megadott könyvtárba.

[WebStaticResourceAttribute(“/resources/images“, typeof(Images))]

A fenti példa az Images statikus erőforrás osztály elemeit elérhetővé teszi a /resources/images könyvtár alatt. Ha az Images erőforrás tartalmaz egy main.jpg nevű fájlt (kép vagy byte[]), úgy a localhost:port/resources/images/main.jpg URL meghívásával az erőfárrásban tárolt fájl kiszolgálásra kerül. Az erőforrásban tárolt adatok kiszolgálása is több szálon folyik, nagy mennyiségű adat vagy nagy méretű kép esetén is megvalósul a párhuzamos, kiegyensúlyozott kiszolgálás.

 

Konklúzió

A webfejlesztők módszereihez igazodva, egy új kép- vagy javascript fájl FTP-re való feltöltése helyett ugyanennyi ráfordítással a fájlt el kell helyezni egy szabványos Resource fájlban. (A Resource fájlban való jelenlét a fájlról egy másolatot készít a Resource könyvtárban. A fájl másolatának szerkesztése vagy felülírása lehetőséget biztosít a fájl megváltoztatására az erőforrásban.)