Symbol eXtension » SaaS és Intranet

“SaaS és Intranet” 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());
}

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.

 

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.)

6. Példa osztályok és metódushívás tesztelése

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

Az SaaS metódusok jelentős része osztályokon (típusos, hierarchikus adathalmazokon) keresztül kommunikál. A bemenő adatok szinte kivétel nélkül XML formátumúak, gyakran a visszaadott érték is struktúrált adat (JSON formátum). Az osztályok forráskódban történő definiálása után szükség van egy olyan formátumú XML fájlra, amely megfelel az osztálynak.

 

Példa osztály letöltése

Ilyen példa osztály tölthetünk le a metóduslista egyik osztályára kattintva. Az osztály lehet bemenő paraméter vagy eredmény.

A kattintás után a böngésző felajánlja az osztályt letöltésre. A példa fájlban minden mező a neki megfelelő adattal ki van töltve, listák és tömbök esetén 3-5 példa adat jelzi, hogy ismétlődési lehetőség is adott.

Adatkitöltő próbaform használata

A letöltött és esetleg módosított XML formátum elküldéséhez nincs szükség külön alkalmazásra. A metódus neve melletti kis “cetlire” kattintva egy olyan, böngészőben megjelenő felületet kapunk, amelyen keresztül az XML fájl (vagy bármilyen más paraméter) elküldhető a metódusnak. Az elküldés után a végeredmény is elemezhető. A végeredmény lehet valamilyen hibakód, XML eredmény vagy információ arról, hogy egy fájl letöltődne.

A próbaform egy külön ablakban jelenik meg és az alábbiak szerint néz ki

Az eredmény csak akkor jelenik meg, ha a “Send data” gomb használatával az adatokat elküldjük. Az ablak korlátlan alkalommal használható, az elküldött adatok az adatbeviteli mezőkben újra megjelennek.

5. Amit nem “szabad”

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

Az SaaS működés elsődlegesen egy kiszolgáló tevékenység. Mivel a SyX környezetben a Symbol Ügyvitel alkalmazás végzi a kiszolgáló tevékenységet, elkerülhetetlen, hogy ki kelljen térnünk a hibás SyX használatra.

Felhasználói tevékenység SaaS metódusban

Nem szabad olyan SaaS metódust írni, amely valamilyen felhasználói tevékenységet végez (és nem ez az fő célja). Kerülni kell az olyan eseteket, amikor az SaaS metódus hívása létrehoz egy bizonylatot, de azt az adatok mentése helyett a Display() metódussal megjeleníti a kiszolgáló számítógépen.

Még nagyobb problémát okoz, ha a kiszolgáló számítógépen beavatkozást igénylő tevékenység kerül végrehajtásra, például megjelenik egy üzenetablak. Az alábbi WebMethod egy üzenetablakot jelenít meg a Symbol Ügyvitelben a linkre kattintva:

        [WebMethod(“Példa web metódus”)]
        public void SampleWebMethod(int a, DateTime b)
        {
            MessageBoxInfo(String.Format(“{0} – {1}”, a, b), “Külső adat”);
        }

Az üzenetablak ideje alatt a többi szálon a kiszolgálás zavartalanul folyik, de a böngésző az üzenetablak OK gombjának megnyomásáig várakozni fog.

4. Hibakezelés és teljesítmény

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

Hibakezelés

A hibák kezelésére elsődlegesen felhasználhatjuk a HTTP protokoll saját hibakezelő rendszerét, amely 200-as eredményt ad vissza, amikor minden rendben van és 3xx, 4xx, 5xx hibákkal jelzi, ha hiba keletkezett.

A SyX SaaS szolgáltatások az alábbi hibajelzési módot támogatják:

  • 200: megfelelő működés
  • 404: nem található a meghívott WebMethod (kis/nagybetű számít)
  • 403: a ModuleDepends attribútum jelenléte miatt a WebMethod nem hívható meg
  • 400: a WebMethod meghívásához szükséges egy paraméter, amit a kiszolgáló nem kapott meg (hibás paraméterezés vagy a paraméter nem konvertálható megfelelő típusra)
  • 500: a WebMethod végrehajtása közben hiba történt

A fent nevezett hibakódokat a rendszer a böngészők és más kliensek irányába továbbítják. A SyX beépülő gazdája a Log műveletek segítségével naplózhatja a hibás működést. Emellett, amennyiben erre szükség van a HTTP hibakódok mellett például bool visszatérési értékkel a hívó félnek jelezheti egy metódus a művelet sikeres végrehajtását.

 

Teljesítmény

A teljesítmény elsődleges szempont az SaaS szolgáltatások tervezésekor. A beérkező kérések azonnal párhuzamos működésre váltanak, a kérések előfeldolgozása, paraméterek ellenőrzése már párhuzamosan kerül végrehajtásra. Ezáltal a folyamatban lévő, beérkező kérések sem lassítják vagy állítják meg a rendszert. A kérések valós kiszolgálása (WebMethod hívása) szükég esetén a főablak szálon kerül végrehajtásra. Ennek bizonyos teljesítménybeli hátrányai lehetnek a lassú WebMethod műveletek esetén.

Performancia szempontból a SaaS SyX beépülők kiváló teljesítmény mutatókkal jellemezhetőek:

localhost-on mérve, apache ab.exe alkalmazással, 1000 kérés, folyamatosan

  • Üres metódus meghívása: 260 művelet/mp
  • Konstans string metódus hívása: 246 művelet/mp
  • Képgenerálás: 137 művelet/mp
  • 404-es hibával visszatérő kérések: 270 művelet/mp
  • Vevő keresése ID-ja alapján: 40 művelet/mp