Használható metódusok és tulajdonságok:

• bool Login(string username, string password): Bejelentkezés.
• void Logout(): Kijelentkezés
• bool Valid: Érvényes bejelentkezés-e?
• LoggedInWebUserInfo: Bejelentkezett felhasználó adatai
• HasPermission(int permission): SyX jogosultság ellenőrzése
• HasSymbolPermission(SymbolPermission permission): Symbol Ügyvitel jogosultság ellenőrzése

• 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"];

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.

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.

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());
}

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.

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.

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.

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.

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

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.

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.

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

Az URL alapú szolgáltatás kezelés lehetővé teszi, hogy böngészőben használjuk a WebMethod-okat, ha azok HTML tartalmat is elő tudnának állítani. A WebMethod, amely string típusú adatot ad vissza, alapértelmezetten TEXT/PLAIN mime típussal kerül visszaküldésre. Ennek megoldására vezettük be a HtmlResponse osztályt. Az osztály segítségével tetszőleges mime típus visszadható és az alapértelmezett string adatok küldése helyett lehetőség van byte[] eredmény visszaadására is. Ez használható képek vagy letölthető tartalom kiszolgálására. Pl.: http://localhost:8800/?pluginicon=true (amennyiben a plugin-nek van ikonja)

Egy teljes Intranet portál megvalósíthatóvá válik a HtmlResponse eredmény típus használatával. Nézzük erre néhány példát:

HTML tartalom létrehozása

A HTML tartlom létrehozása a programozó vagy a designer feladata. A HTML stípusok, DIV-ek, TABLE-k kezeléséhez a SyX SDK nem nyújt támogatást. A létrehozott HTML tartalom megfelelő megjelenítéséhez használható a HtmlResponse osztály.

Nézzük az alábbi példát, ahol egy StringBuilderben összeállított HTML tartalmat szolgálunk ki a böngésző felé. (SaaS módban valószínüleg a hívó fél nem tud mit kezdeni a HTML formázott szöveggel)

        [WebMethod("Példa web metódus V.")]
        public HtmlResponse SampleWebMethodHTML()
        {
            StringBuilder sb = new StringBuilder();
            sb.AppendLine(“<html>”);
            sb.AppendLine(“<body>”);
            sb.AppendLine(“<center>Példa szöveg”);
            sb.AppendLine(“<img src=’http://www.symboltech.hu/images/slide_easy.jpg’></center>”);
            sb.AppendLine(“</body>”);
            sb.AppendLine(“</html>”);
            return new HtmlResponse(sb.ToString());
        }

A HtmlResponse alapértelmezetten Text/HTML MIME típusú adatot ad vissza UTF8 kódolással, az átadott HTML formátumú szövegen túl, semmilyen paraméter nem szükséges.

Képek, dokumentumok kiszolgálása

Képek vagy dokumentumok kiszolgálhatóak a HtmlResponse osztály konstruktorának byte[]-bel való meghívásával. Az eredmény típusának megadása fontos, mert a böngésző a MIME típus alapján fogja kiválasztani a megjelenítés vagy letöltés módját.

Készítsünk egy képet futási időben, írjunk rá egy szöveget és adjuk vissza a böngészőnek JPEG formátumban:

        [WebMethod("Kép létrehozása")]
        public HtmlResponse SampleWebMethodImage()
        {
            using (Bitmap bmp = new Bitmap(320, 160))
            using (Graphics g = Graphics.FromImage(bmp))
            using (MemoryStream stream = new MemoryStream())
            {
                g.Clear(Color.Gray);
                g.DrawString(“Példa kép”, new Font(“Arial”, 28), new SolidBrush(Color.Orange), 20, 20);

                bmp.Save(stream, ImageFormat.Jpeg);
                stream.Position = 0;
                return new HtmlResponse(stream.ToArray(), null, System.Net.Mime.MediaTypeNames.Image.Jpeg);
            }
        }

Állítsunk elő egy letölthető dokumentumot (lehetne az adatbázis csatolt dokumentumai közül is kiválasztani egyet):

        [WebMethod("Dokumentum letöltése")]
        public HtmlResponse SampleWebMethodDocument()
        {
            StringBuilder sb = new StringBuilder();
            sb.AppendLine(“Első sor”);
            sb.AppendLine(“Második sor”);
            sb.AppendLine(“3. sor”);

            return new HtmlResponse(sb.ToString(), “sample.txt”, MediaTypeNames.Application.Octet);
        }

Vegyük észre, hogy az előző példában szereplő kép létrehozás is letöltésre kínálja fel a képet, ha a NULL érték helyett megadunk egy fájlnevet!

Átirányítás kezelése

Intranet portálok esetén előfrodulhat, hogy a HTML tartlom helyett valamely más (belső) oldalra kell átirányítani a böngészőt. Ezt szintén a HtmlResponse eredmény használatával érhetjük el:

        [WebMethod("Példa web metódus REDIRECT")]
        public HtmlResponse SampleWebMethodRedirect()
        {
            return HtmlResponse.Redirect(“/SampleWebMethodHTML”);
        }

Alapértelmezett főoldal beállítása

Nyilvánvaló az igény, hogy ha Intranet portált üzemeltetünk, akkor egy főoldalon ne az elérhető szolgáltatások listája jelenjen meg, hanem a fő szolgáltatás. Ezt megadhatjuk a SyX WebStartPage attribútumával. Ennek paramétere a főoldal lekérésekor (http://localhost:8800) megjelenő szolgáltatás, amelynek tipikusan metódus nélkülinek és HtmlResponse visszatérésű értékünek kell lennie.

[WebStartPage("SampleWebMethod2a")]

404-es hibaoldal beállítása

A nem elérhető, rosszul címzett oldalak helyett lehetőség van (az alapértelmezett főoldalhoz hasonlóan) egy hibaoldalt megadni. A hibaoldal lehet egy erre a célra létrehozott oldal vagy egy létező, működést megvalósító oldal, például a főoldal. A 404-es hibaoldal minden esetben átirányítással valósul meg. Az erőforrások, képek hibás URL-jei nem kerülnek átirányításra, ilyen esetben HTTP 404-es hibát kapunk (kép helyett piros X jelenik meg a böngészőben).

[Web404Page("SampleWebMethod4")]

A favicon.ico kezelése

A rendszer automatikusan kezeli a favicon.ico image/x-icon típsuként való kiszolgálását. A SyX beépülő iconja alapján hoz létre egy ICO formátumú képet, amelyet a kérés beérkezésekor kiszolgál.

A metódusnak lehet nulla, egy vagy több paramétere és visszatérési értéke is lehet void, valamilyen primitív típus vagy tetszőleges (akár saját) osztály is.

Metódusok létrehozása

Az alábbi példa egy olyan metódust hoz létre, amely eredményül egy szöveget ad vissza. Ez a böngészőben meg is jelenik (akár a főképernyőn a linkra kattintva is). A metódus meghívásra kerül, ha a böngészőben az alábbi linkre kattintunk: http://localhost:8800/SampleWebMethod2a

        [WebMethod("Példa web metódus II/a.")]
        public string SampleWebMethod2a()
        {
            return String.Format(“A_{0}_X”, “StartPage”);
        }

A következő metódus paramétert is vár, amelyet felhasznál az eredmény létrehozakor. Meghívásakor át kell adnunk egy paramétert: http://localhost:8800/SampleWebMethod2?s=pelda

        [WebMethod("Példa web metódus II.")]
        public string SampleWebMethod2(string s)
        {
            return String.Format(“A_{0}_X”, s);
        }

Paraméterek átadása

A paraméterek átadhatóak a meghívott URL-ben is ?-lel és & jellel elválasztva, illetve nagyobb mennyiségű adat esetén (URL max. 512 karakter) POST adatok között is. Mindkét meghívási mód UTF8 kódolású karaktereket vár és ad vissza. A GET és POST módszer kiváló lehetőséget biztosít arra, hogy az URL-ek meghívása, a szolgáltatások használata ne csak böngészőből legyen elérhető, hanem tetszőleges programozási nyelven írt alkalmazásból, amely képes HTTP kommunikációra.

Gyakran változó paraméterek

Amennyiben a metódushívás egy böngésző űrlapjáról jön, nehéz előre megadni minden változót, a típusosság ilyen esetben hátrány lehet. A gyakrban változó paraméterekre két megoldás létezik. A nullozható (int?, string, class) típusok használata esetén a paramétert nem kell átadni, lehetőség van arra, hogy azt elhagyjuk a metódus hívásakor. A metódus törzsében ilyenkor a .HasValue használata erősen javasolt.

        [WebMethod("Példa web metódus Nullable")]
        public string SampleWebMethodNull(int a, DateTime? b, decimal? c)
        {
            return String.Format(“{0} – {1} – {2}”, a, b, c);
        }

http://localhost:8800/SampleWebMethodNull?a=17

A másik – teljes szabadságot adó - megoldás, amikor a webmethod egyetlen paraméterének típusa Dictionary<string, string>. Ilyenkor a kapott összes paramétert egy dictionary típuson keresztül lehet feldolgozni. Ez lehetővé teszi, hogy paraméterek létezésére vizsgáljunk. Ugyanezen módszer jelent megoldást arra is, ha olyan sok paraméterrel (>15) dolgozunk, amely egy erősen típusos webmethod paraméterlistáját kezelhetetlenné tenné.

        [WebMethod("Példa web metódus - Dynamic")]
        public string SampleWebMethodDynamic(Dictionary<String, String> parameters)
        {
            List<string> result = new List<string>();
            foreach (KeyValuePair<string, string> kv in parameters)
                result.Add(String.Format(“{0}: {1}”, kv.Key, kv.Value));
            return String.Join(“\n”, result.ToArray());
        }
Eredmény típusa

A metódusok visszatérési értéke is tetszőleges típus lehet. Ezt a rendszer string-gé konvertálja majd így adja vissza (vagy jeleníti meg a böngészőben).

Összetett típusok használata

A primitív típusok mellett tetszőleges osztályok paraméterként való átadására és eredményként való kinyerésére is lehetőség van. Az osztályok adatai XML sorosítás után kerülnek átadásra. Ez lehetővé teszi, hogy szövegként átadhatóak legyenek és tetszőleges mélységű, hirerchikus adat közvetítésére is lehetőség van. A kapcsolófelület megváltozásakor (pl.: osztály bővítése) az XML sorosítás következtében a két illeszkedő felületet nem kell egyidőben cserélni. A fogadó fél a kiszolgáló válaszában található hozzáadott adatokat figyelmen kívül hagyhatja.

Például az alábbi osztály a SyX-en belül definiáljuk, majd felhasználjuk egy SaaS szolgáltatás visszatérési értékeként:

        public class WebMethodResult
        {
            private int a = 1979;

            public int A { get { return a; } set { a = value; } }
        }

        [WebMethod("Példa web metódus III.")]
        public WebMethodResult SampleWebMethod3()
        {
            return new WebMethodResult();
        }

Felhívjuk a figyelmet, hogy összetett adattípusok használatakor kerüljük a rendszer belső, bonyolult adattípusait, amelyek sorosítása nagyon nagy adatmennyiséget generál. Például a Symbol Ügyvitel entitásainak vagy a .NET DataTable osztályának sorosítása több MB felesleges adatot jelenít meg az XML-ben.

Ajax és JSON

Amennyiben az eredmény osztály típusú, úgy lehetőség van az XML formátum helyett JSON formátumot választani. A webmethod esetén alkalmazni kell a JsonResult attribútumot. Ilyenkor a metódus visszatérési osztálya nem XML sorosítással fog a kimenetre kerülni, hanem JSON formátumban. Emellett pedig az eredmény MIME típusa Application/Json lesz. Ez a megoldás használható Ajax környezetben is összetett típusok visszaadására.

Metódusnév és URL kapcsolata

A meghívott URL végződése alapján, betűnagyság érzékenyen kerül kiválasztásra a megfelelő metódus. A paraméterek nem sorrend és betűnagyság érzékenyek. A metódus nevének kiválasztásakor a pontokat _ jelre cseréli a rendszer, ezáltal a fájl hivatkozások (tables.js, leftcorner.jpg) is metódusokra fordíthatóak (tables_js(), leftcorner_jpg()). Statikus fájlok esetén javasolt a WebStaticResource attribútum használata!Jelenleg a rendszer nem kezeli a túlterhelt metódusokat (egy név, több féle paraméterezés).

Eddig a SyX beépülők funkciója az volt, hogy a meglévő funkciókat egészítsék ki, új menüpontokat vagy vezérlőket hozzanak létre, illetve beépített időzítőkkel rendszeresen műveleteket végezzenek. Ezek a műveletek használhattak Internetes kommunikációt, de a műveletet a Symbol Ügyvitel kezdeményezte. Eddig.

SaaS kiszolgálóként a SyX-ek egy megadott TCP porton keresztül HTTP kommunikációt folytatnak, kéréseket fogadnak és kiszolgálják azokat. A kiszolgálás járhat szöveges/XML eredménnyel, amelyet a metódusok vissza tudnak küldeni. Az SaaS szolgáltatást típusos metódusokkal tudjuk feldolgozni, minden adat a C# nyelv szintaktikája alapján jelenik meg a SyX-ben. Mindezt egyéb webkiszolgáló (IIS, Apache) nélkül.

Mi szükéges hozzá, hogy SaaS szolgáltatásokat tudjunk létrehozni?

A SyX beépülőben meg kell adni az alábbi attribútumot, amelyben beállíthatjuk, hogy melyik porton fogadjuk a kéréseket:

[WebPort(8800)]

Ezután a SyX (akár a fejlesztői konzolból indítva) a 8800-as porton hallgatózik és a böngészőbe beírva az alábbi linket, működőképes választ kell kapnunk: http://localhost:8800/

A böngészőben megjelenik a SyX neve, ikonja és a SyX kiszolgálható metudósok listája, mint az alábbi képen:

A linkekre kattintva azonnal meg is tudjuk hívni a metódusokat, azok eredménye a böngészőben fog megjelenni.

Az SaaS működés elve, hogy a megfelelően paraméterezhető metódusokat HTTP kérésék (POST vagy GET) segítségével meghívjuk, majd amennyiben azok valamilyen eredménnyel érnek véget, arról értesítést kaphatunk. A végrehajtott műveletek lehetnek:

• Lekérdezések: A paraméterül átadott adatok alapján egy lekérdezést állítunk össze, amely akár nagy méretű adathalmazt is visszaadhat eredményül.
• Műveletek: A paraméterül adott adatok alapján valamilyen műveletet végzünk, amelynek bizonyos esetekben eredménye is lehet. Ilyenkor egy nem VOID metódust kell létrehozni.

Fontos ismételten hagnsúlyozni, hogy az SaaS működéshez nincs szükség semmilyen egyén webkiszolgálóra (IIS, Apache).

        [MenuCustomListCommand("Egyedi command", "SampleCustomList")]
        public void SampleCustomListEx(DataRow row)
        {
            MessageBox.Show(row[0].ToString());
        }

Hozzunk létre egy új metódust, amelynek egy paramétere van, amely egy DataRow (ebben fogjuk megkapni az éppen kiválasztott sort). A MenuCustomListCommand attribútum segítségével megadhatjuk, hogy mi legyen az új funkció neve és mely egyedi listán jelenjen meg.

Az egyedi listán egynél több művelet is elhelyezhető. A műveletek a deklarálásuk sorrendjében fognak megjelenni. Az első művelet lesz a kiemelt, amely lista ENTER vagy duplaklikk eseményére aktiválódik.

A műveletekhez a megszokott módon ikon (32×32) is rendelhető.

Az új művelet maga bármilyen C# kódrészlet lehet. Amennyiben itt egy újabb ablakot szeretnénk megjeleníteni (pl.: összesítő lista kibontása), úgy használhatjuk a this.DisplayCustomList(“Egyedi ablak”, image, datatable) metódust. Ez új ablakot jelenít meg az átadott elnevezéssel, ikonnal és adattartalommal.

Egy vagy több cégnév megadására is van lehetőség:

[CompanyNamePermission("Alma Kft.", "")]

[CompanyNamePermission("Symbol LAB", "Symbol Tech Kft.")]

Például, a Symbol Ügyvitel v1.66-es verziójától elérhető a Szerződéses árak telephelyhez való rendelése. Amennyiben a SyX beépülő ezt használja, meg kell adni a

[RequiredVersion(1, 66)]

attribútumot, hogy csak azok a felhasználók érhessék el, akik frissítettek v1.66-ra.

                using (EntityHandler handler = CreateEntityHandler(false))
                {
                    long? seq = SelectVoucherSequence(SymbolVoucherType.Invoice);
                    if (!seq.HasValue)
                        return;
                    StockOut inv = handler.StockOutAdapter.CreateNewObject();
                    inv.VoucherSequence = seq.Value;
                    inv.VoucherType = SymbolStockOutVoucherType.Invoice;
                    inv.CustomerObj = handler.CustomerAdapter.SelectAll(true)[0];
                    inv.Display();
                }

Fontos megjegyezni, hogy:

• A kódrészlet ugyan a using-ból való kilépés miatt felszabadítaná (elengedné) az objektumot, de a számlát megjelenítő ablakból hivatkozva a StockOut objektumra, az a memóriában marad.
• EntityHandler létrehozásakor fontos, hogy false paraméterrel hívjuk meg, mert a using elhagyásakor még nem kell (nem is tudnánk) elmenteni a StockOut objektumot.

                using (ProgressForm prog = CreateProgressForm(“Vevők létrehozása”))
                using (EntityHandler handler = CreateEntityHandler())
                {
                    CustomerCollection cc = handler.CustomerAdapter.CreateEmptyCollection();
                    for (int i = 0; i < 5; i++)
                    {
                        prog.UpdateStatus(String.Format(“{0}. vevő”, i));

                        Customer cust = cc.AddNew();
                        cust.CustomerStatus = true;
                        cust.Code = new Random().Next(1000000).ToString() + i.ToString();
                        cust.Name = String.Format(“Symbol {0} Tech Kft.”, i);
                        cust.InvoiceZip = “1135″;
                        cust.InvoiceCity = “Budapest”;
                        cust.InvoiceStreet = “Lehel út 61.”;
                        cust.PaymentMethodObj = handler.PaymentMethodAdapter.SelectAll(true)[0];
                        Log(LogType.Info, String.Format(“Fiz.mód: {0}”, cust.PaymentMethodObj.Name));
                        for (int j = 0; j < 3; j++)
                        {
                            CustomerAddress addr = cust.ChildCustomerAddressByCustomer.AddNew();
                            addr.Name = String.Format(“Telephely: {0}”, j);
                        }
                    }
                    Log(LogType.Info, String.Format(“{0}db vevő létrehozva”, 5));
                }

Például:

Új menüpont létrehozását támogató metódus előtt elhelyezett [ModuleDepends(SymbolModule.WebData)] attribútum korlátozza, hogy a menüpont csak akkor jelenjen meg, ha a cégnek van WebData modulja.

A rendszeres időzítés céljából hozzunk létre egy Timer-t, majd:

• Állítsuk be a Timer Interval értékét a rendszerbeállítások alapján (amelyet a felhaszáló például egy külön ablakon szerkeszthet).
• A Tick eseményre kössük rá a végrehajtani kívánt metódust.
• A StartUp() metódusban indítsuk el az időzítőt.
• A ShutDown() metódusban állítsek le az időzítőt.

A Log() metódussal precízen naplózhatjuk az időzítő indulását, leállítását és tevékenységét.

Működés jellemzői:

• Az üzenet törzse HTML tartlmú is lehet. Ilyen esetben automatikusan létrejön a Text/Plain melléklet, amely a csak szöveges részeket tartalmazza.
• A csatolt fájloknak az üzenet küldésének idején végig létezniük kell. Az üzenet sikeres kiküldése után a fájlok törölhetőek.
• Kivétel keletkezik, ha az üzenet nem került elküldésre. Ennek lekezeléséről a SyX beépülőnek kell gondolskodnia.

Bizonylatok előállítása PDF formátumban és kiküldésül email üzenetként a megadott email sablon használatával:

• void SendVoucherEmailCustomerBid(long emailvouchertemplate, long customerbid, bool firstpageonly)
  Árajánlat kiküldése PDF formátumban a vevő email címére.
• void SendVoucherEmailCustomerOrder(long emailvouchertemplate, long customerorder, bool firstpageonly)
  Vevői rendelés kiküldése PDF formátumban a vevő email címére.
• void SendVoucherEmailStockOut(long emailvouchertemplate, long stockout, bool firstpageonly, int vouchertype)
  Szállítólevél, számla kiküldése PDF formátumban a vevő email címére (utolsó paraméterként szükséges megadni a bizonylat típusát)

string CreatePDFFromCustomerBid(long customerbid, bool firstpageonly)

Árajánlatból PDF készítése.

string CreatePDFFromCustomerOrder(long customerorder, bool firstpageonly)

Vevői rendelésből PDF készítése.

string CreatePDFFromStockOut(long stockout, bool firstpageonly)

Szálíltólevélből, számlából (bármilyen készlet(ki)mozgató bizonylatból) PDF készítése.

A metódus felülírásával bizonyos adatok (adatbázis tábla szerint) bizonyos műveletei (adatbázis műveletek = Insert, Update, Delete) alapján dönthetünk arról, hogy a SyX beépülő végrehajtson-e egy műveletet.

Minden adatváltozás megjelenítése üzenetablakban:

        protected override void EntityChanged(PlugInEntityChangeInfo[] entitychangeinfos)
        {
            List<string> s = new List<string>();
            foreach (PlugInEntityChangeInfo pieci in entitychangeinfos)
                s.Add(String.Format(“{0} {1} {2}”,
                     pieci.EntityType,
                     pieci.EntityChangeMode,
                     pieci.Id));
            MessageBox.Show(String.Join(“\n”, s.ToArray()));
        }

Működési modell jellemzői:

• Az adatváltozásról szóló értesítés csak akkor érkezik meg, ha az adatok mentése sikeres volt. Tranzakció visszagörgetésekor semmilyen változás értesítés nem fut be.
• A tranzakció közben mentett adatok (új számla, azon egy új vevő, és egy most létrehozozz fizetési mód, majd a számla 15 tétele) együttesen érkeznek be az értesítési folyamatba. Táblánként lehet dönteni arról, hogy mely adatokkal foglalkozunk. A megkapott Id azonosítókon keresztül hozzáférünk a már mentett adatokhoz.
• A fenti példával ellentétben nem célszerű felhasználói beavatkozást igénylő műveleteket kötni az adatváltozáshoz.

Felhasználási példa:

• Adott bizonylattömbbe rögzített, 1M Ft-nál nagyobb vevői rendelésről automatikusan értesítést küld a rendszer a vezetőnek.
• Számla pénzügyi kiegyenlítésekor automatikusan SMS-t küld a vevőnek.

long? SearchCustomer()

Vevő kiválasztása füles keresővel

long? SearchSupplier()

Szállító kiválasztása füles keresővel

long? SearchProduct()

Termék kiválasztása füles keresővel

long? SearchMaintenanceProduct()

Javításra leadott termék kiválasztása füles keresővel

long? SearchLead()

Érdeklődő kiválasztása füles keresővel

long? SearchCampaign()

Kampány kiválasztása füles keresővel

long? SelectVoucherSequence(SymbolVoucherType symbolvouchertype)

Bizonylattömb kiválasztása adott bizonylattípushoz. Amennyiben egy ilyen bizonylattömb létezik, úgy a rendszer azt adja vissza. Több bizonylattömb esetén a felhasználónak lehetőséget biztosít a választásra.

Minden füles keresővel való kiválasztás NULL értéket ad vissza, ha a mégsem gombot nyomja meg a felhasználó. Amennyiben a visszaadott érték nem NULL, úgy egy long típusú (akár 64bites) értéket ad, amely a keresett adat egyedi azonosítója (table.ID). Ezt felhasználhatjuk az Entitásokon keresztüli műveleteknél.

Felhasználási javaslat:

• Külső fájlból érkezett rendelés feldolgozása esetén nem azonosítható a vevő, ezért a vevőkereső funkcióval választunk a meglévő vevők közül.
• Nem minden termék azonosítható, azért a termékválasztó segítségével pontosítjuk az adatokat.

A megjelenítéshez hozzuk létre a megfelelő vezérlőt és hívjuk meg a megjelenítő metódust. Praktikus ellenőrizni, hogy a vezérlő már létezik-e.

        [MenuCommand("HelloWorld: Control létrehozása", MenuCommandLocation.Tools)]
        public void CreateAndDisplayControlUC()
        {
            if (ucdisplay != null) return;

            ucdisplay = new UCDisplay();
            this.DisplayMainFormControl(ucdisplay, “Próba Control”);
        }

A vezérlő elrejtésére is van megfelelő metódus. Ilyen esetben is ellenőrizzük, hogy a vezérlő létezik-e még.

        [MenuCommand("HelloWorld: Control megszűntetése", MenuCommandLocation.Tools)]
        public void HideControlUC()
        {
            if (ucdisplay != null)
            {
                this.HideMainFormControl(ucdisplay);
                ucdisplay = null;
            }
        }

A létrehozott és megjelenített vezérlő bármilyen egyéb vezérlp tárolására alkalmas. Amennyiben a megjelenített panel-en gombokat, grid-eket kívánunk megjelentetni, lehetőségünk van ezt design módban is megtenni a SyX fejlesztése közben.

A megjelenített vezérlő mozgathatóságáról és pozíciójának elmentéséről a keretrendszer gondoskodik.

A létrehozott vezérlő általánosságban megjeleníthető a StartUp() és elrejthető a ShutDown() metódusokban, ilyenkor a Symbol Ügyvitel futása közben állandóan látszik.

Felhasználási példák:

• Tőzsdei grafikonokat megjelenítő UserControl létrehozása, megjelenítéskor (és adott időközönként rendszeresen) adatok lekérése az Interneten keresztül.
• Külső állományok meglétének ellenőrzése és azok feldolgozása. Külső rendszerrel való együttműködéskor egy megosztott mappát figyelhet a SyX beépülő. Amikor abban megfelelő fájlok tűnnek fel (pl.: rendelés XML), azokat feldolgozásra meg lehet jeleníteni egy listában.
• Menüpontoknál is elérhetőbb helyekre elhelyezett funkciók. Például az Email/SMS küldés funkció elhelyezhető a főablakon két nagy gombbal, a menüpontokban való keresgélés (shortcut is van!) helyett.

A lista létrehozásához két dolgot kell tennünk.

• Hozzunk létre egy osztályt a PlugInListFilter osztályból származtatva. Ezáltal szűrőfeltételeket adhatunk a listához.
• Hozzunk létre egy metódust, amelynek egyetlen paramétere egy PlugInListFilter-ből származó osztály, visszatérési értéke pedig DataTable.

Példa PlugInListFilter leszármazottra

        public class SampleListFilter : PlugInListFilter
        {
            private int i = 3;
            private string str = “AAA”;
            private PlugInDateInterval voucherdate =
               new PlugInDateInterval(
                   new DateTime(2011, 1, 1),
                   new DateTime(2011, 12, 31));
            private Customer customer;

            [PlugInFilterCaptionAttribute("Szám")]
            public int I { get { return i; } set { i = value; } }

            [PlugInFilterCaptionAttribute("Név")]
            public string Str { get { return str; } set { str = value; } }

            [PlugInFilterCaptionAttribute("Dátum")]
            public PlugInDateInterval VoucherDate
            { get { return voucherdate; } set { voucherdate = value; } }

            [PlugInFilterCaptionAttribute("Vevő")]
            public Customer Customer { get { return customer; } set { customer = value; } }
        }

A fenti példában a szűrőosztálynak egy szám, egy string, egy dátumintervallum és egy vevő a paraméterei. Ezek a lista megnyitása után, a CTRL+F billentyűvel a szokott módon elérhetőek. A keretrendszer felel érte, hogy a megfelelő adatmezőkhöz a megfelelő beviteli mezők jöjjenek létre: szám=spinedit, szöveg=textedit, dateinterval=intervallum választó, customer=vevőválasztó.

A szűrőosztályban lehetőség van alapértelmezett adatok megadásása is, dátum intervallum típusú mező megadása kötelező!

Példa egyedi listára

        [MenuCustomList("Egyedi lista példa", MenuCommandLocation.Tools)]
        public DataTable SampleCustomList(SampleListFilter filter)
        {
            string cmd = @”
                SELECT p.”"Id”" AS “”Azonosító”", p.”"Name”" AS “”Név”", p.”"Code”" AS “”Kód”"
                FROM “”Product”" p
                WHERE p.”"Name”" LIKE ‘A%’
                      {0}
                ORDER BY 2″;

            List<string> where = new List<string>();
            if (!String.IsNullOrEmpty(filter.Str))
                where.Add(@”AND p.”"Code”" NOT LIKE ‘%T’”);
            if (filter.Customer != null)
                where.Add(@”AND p.”"Id”" == ” + filter.Customer.Id.ToString());
            if (filter.VoucherDate.Filled)
                where.Add(@”AND p.”"CreateDateTime”" > ‘” + filter.VoucherDate.DateFrom + “‘”);

            using (EntityHandler handler = CreateEntityHandler(false))
                return handler.ExecuteQuery(String.Format(cmd, String.Join(” “, where.ToArray())));
        }

A példa alapján egy új menüpont jön létre az Esközök menüpontban. A lista megnyitása után a korábbi szűrőfeltételekkel dolgozhatunk. A lista adatainek lekérdezéséért az itt definiált egyedi SQL Select a felelős. Ebben a szűrőoszály mezőit felhasználhatjuk.

A végeredmény visszaadásához használjuk az EntityHandler megfelelő metódusát, amely DataTable típusú adatot ad vissza.

Példa egy SELECT futtatására, ahol csak a SELECT miatt hozunk létre egy adatbáziskapcsolatot:

   using (EntityHandler handler = CreateEntityHandler(false))
                return handler.ExecuteQuery(“SELECT * FROM “”Customer”" c”);

Entitás osztályok kibővítése

Az SDK részét képező entitás osztályok partial class-kétn kerültek megvalósításra, így a SyX-ek maguk tartalmazhatnak további üzleti logikákat, amelyekkel a gyári funkaiconalitást bővíteni lehet. Például:

A ToString() metódus felülírható (override), ezáltal a gyáritól eltérő viselkedés hozható létre.

Új metódusokat lehet létrehozni, amelyek az adott entitás osztályhoz köthetőek. Például adatellenőrzés.

Új property-ket lehet létrehozni, amelyek nem kerülnek tárolásra, de valamilyen speciális funkcióval bírhatnak. Páldául a Customer osztályt AddressConcatenate property-vel bővítve a cím mezők egymás után fűzött szöveges mezőként is rendelkezésre állnak, például két vevő összehasonlításához vagy rendezéséhez.

Entitásgyűjtemény osztályok kibővítése

Az entitás osztályokhoz hasonlóan az entitásgyűjtemény osztályok is kibővíthetőek új metódusokkal, property-kkel.

Eredeti üzleti logika alkalmazása

Mivel az entitások a Symbol Ügyvitel alkalmazás memóriaterületén jönnek létre, az ott használt üzleti logika automatikusan alkalmazásra kerül, azt kikerülni nem is lehet. Például:

• Rendszerbeállítástól függően, az új vevő/szállító (Customer) adatok létrehozásukkor automatikusan kapnak kódot. Ez a működés akkor is igaz, amikor CustomerAdapter.CreateNewObject() vagy CustomerAdapter.CreateEmptyCollection.AddNew() hatására egy új objektum jön létre.
• Számla dátumainak módosításakor, számla mód (ÁFA58, gyűjtőszámla) függvényében automatikusan beállításra kerülnek a dátumok.
• Bizonylatok tételeinek módosításakor a bizonylat fejben tárolt nettó. áfa, bruttó összegek automatikusan kiszámolásra kerülnek. A kerekítési szabályok a beállított pénznem alapján kerülnek alkalmazásra.

Az EntityHandler példány annyi Adaptert tartalmaz, ahány féle táblánk van az adatbázisban. A Customer entitás kezeléséhez az EntityHandler.CustomerAdapter, a Product entitás-hoz pedig az EntityHandler.ProductAdapter lesz segítségünkre. Az adapterek az alábbi metódusokat tartalmazzák (a metódushívások a using (EntityHandler handler = CreateEntityHandler()) blokkon belül értendőek):

• CustomerCollection CreateEmptyCollection(): Üres entitásgyűjtemény létrehozása, amelyhez entitásokat adhatunk hozzá vagy a gyűjtemény AddNew() metódusát meghívva új entitást hozhatunk létre benne.
• Customer CreateNewObject(): Új entitás példány létrehozása önállóan. Az entitás nem egy gyűjteményben jön létre, önállóan létezik.
• CustomerCollection SelectAll(): Összes entitás lekérdezése és elhelyezése egy entitás gyűjteménybe. (WHERE nélküli SELECT). Amennyiben az entitásnak van Deleted mezője, úgy a SelectAll() paramétere a ShowDeleted, amely alapján eldől, hogy minden elemet vagy csak a nem törölteket jelenítsük meg.
• Customer SelectByPK(long id): Adott ID-jú elem beolvasása és létrehozása önálló entitásként.
• CustomerCollection SelectByCondition(WhereClause whereclause): Megadott SQL WHERE szűrőfeltételeknek megfelelő adatbázis sorok kiolvasása a táblából.

WhereClause?

A WhereClause egy típusos WHERE feltétel megírását támogató eszköz. Amennyiben a tábla és mezőneveket pontosan kívánjuk megadni, úgy célszerű használni az XXXField konstansokat.

Például:

                    WhereClause wc = CustomerField.Phone == “20-555-7845″ | CustomerField.Name == “Csaba”;
                    CustomerCollection cc = handler.CustomerAdapter.SelectByCondition(wc & CustomerField.PaymentMethod != 12);

A CreateEntityHandler metódus hasznlatával az alábbi módon hozhatunk létre adatbázis kapcsolatot:

                using (EntityHandler handler = CreateEntityHandler())
                {
                     …

                }

A létrehozozz adatbázis kapcsolatot minden esetben using kulcsszóval kell használni, hogy szigorúan vezéreljük a kapcsolat bezárását. A Microsoft Entity Framework-höz hasonlóan az EntityHandler példány ideje alatt minden adatbázis elemhez hozzáférhetünk, azokat módosíthatjuk, majd az EntityHandler megszűnésekor a változások rögzítésre kerülnek az adatbázisban.

Az EntityHandler használata során létrehozott adatok csak addig érhetőek el, amíg az EntityHandler létezik!

Meddig tartsam nyitva az adatbázis kapcsolatot?

Az adatbázis kapcsolatot addig kell és szabad nyitva tartani, amíg arra szükség van. Az alábbi ökölszabélyokat célszerű figyelembe venni:

• Adatbázis kapcsolatot az első adat elérése előtt létre kell hozni
• Adatbázis kapcsolatot az utolsó adathoz való hozzáférés után meg kell szüntetni
• Egy metódushíváson belül nem célszerű több alkalommal létrehozni az adatbázis kapcsolatot, inkább a using blokkot kell úgy szervezni, hogy az hosszabb ideig legyen nyitva.
• Nem szabad egymásba ágyazott adatbázis kapcsolatot létrehozni
• Egy adatbázis kapcsolaton belüli adatmentés (kivéve az implicit esetet) egy tranzakcióban valósul meg

Nem akarok minden adatok menteni

Lehetőség van arra is, hogy az EntityHandler használata során betöltött és megváltoztatott adatok ne kerüljenek mentésre. Ilyenkor a CreateEntityHandler(false) hívási módot kell használnunk. Az adatok mentését implicit módon, a SaveChanges() meghívásával kell elvégeznünk.

A using nélkül használt EntityHandler-re a Symbol Tech Kft. nem adja ki a SyX tanúsítványt!

using(ProgressForm prog = CreateProgressForm(“Folyamatjelzés folyamatban…”))

{

    for(int i=0;i<100;i++)

    {

        prog.UpdateStatus(String.Format(“{0}. lépés”, i));

        System.Threading.Thread.Sleep(50);

    }

}

A folyamatjelző ablak a Dispose() lefutása után (using!) automatikusan eltűnik.

Gyakori igény, hogy a folyamat közben a folyamatjelző csík átmenetileg eltűnjön, helyet adva valamilyen felhasználói tevékenységet igénylő ablaknak. Ebben segít a ProgressHider CreateProgressHider() metódus, amelyet szintén using kulcsszó mellett kell használni. A using idejére a folyamatjelző ablak elrejtésre kerül.

using(CreateWaitCursor())

{

  hosszabb művelet…

}

A homokóra a Dispose() lefutása után (using!) automatikusan eltűnik.

void Log(LogType logtype, string message)

void Log(LogType logtype, string message, string description)

void Log(string location, Exception ex)

Naplózást valósít meg. A naplóbejegyzések bekerülnek az adatbázisba, és SyX konzol használata esetén a felületen is megjelennek. Paraméterezési lehetőég, hogy részletes információt is meg lehet adni a naplózáskor. Ennek mérete max 2GB lehet.

Lehetőség van a hibát közvetlenül naplózni. Ilyen esetben a LogType értéke Error lesz, az Exception szövege és a TrackTrace pedig bekerül a részletes leírásba.

void Debug(LogType logtype, string message)

A Log metódus mintájára lehetőség van naplózásra, de a naplózás csak DEBUG üzemmódban kerül meghívásra. Ezzel megoldható, hogy csak fejlesztési időben szükséges naplózási funkciók is benne maradhassanak a forráskódban.

CompanyInfo GetCompanyInfo()

A rendszer cégadatainak elérésére szolgáló metódus.

LoggedInUserInfo GetLoggedInUserInfo()

A bejelentkezett felhasználó adatainak elérésére szolgáló metódus.

void MessageBoxInfo(string text, string caption)

void MessageBoxError(string text, string caption)

void MessageBoxException(string location, Exception ex)

void MessageBoxQuestion(string text, string caption)

Különböző stílusú, szabványos üzenetablakok megjelenítése. Megjeleníthető információs, hibajelző, kérdés ablak.

void SetSystemSetting(string name, object value)

void SetUserSetting(string name, object value)

object GetSystemSetting(string name)

object GetUserSetting(string name)

Rendszerfüggő (cégfüggő) és felhasználóhoz köthető beállításor írása és olvasása. A SyX beépülőnek nem kell megvalósítania a beállítások tárolását, nem szükséges (sok esetben, biztonsági okokból nem is lehetséges) a registry írása/olvasása. A Symbol Ügyvitel lehetőséget biztosít, hogy SyX beépülőnként tároljuk a rendszer és felhasználói szintű beállításokat. A beállítások értékének sorosíthatónak kell lennie és a biztonságok típuskonverzióról (Convert.ToXXX()) a felhasználónak kell gondoskodnia.

bool StartUp()

SyX beépülő indításakor meghívásra kerülő metódus. Célja, hogy az induláskor elvégzendő műveleteket meg lehessen valósítani. Példa: A konstruktorban létrehozott Timer indítása.

bool ShutDown()

SyX beépülő leállításakor meghívásra kerülő metódus. Célja, hogy a folyamatosan használt erőforrásokat felszabadítsuk. Példa: A StartUp()-kor elindított Timer leállítása. A ShutDown() metódus után a StartUp() metódus meghívása elképzelhető, a használt objektumokat nem szabad felszabadítani.

Image GetPlugInIcon()

SyX beépülő ikonjánat kinyerésére szolgáló metódus. Célja, hogy a SyX beépülőhöz rendelt ikon megjelenhessen az Eszközök menüben.

Image GetMethodIcon(string methodname)

SyX beépülő által definiált új menüpontok és ribbon gombok ikonjának kinyerésére szolgáló metódus. A metódusnak egy, legalább 32x32px-es, lehetőleg 24bites PNG, JPG, BMP ikont kell visszaadnia. A nagy méretű ikonok automatikusan átméretezésre kerülnek.

• Hozzunk létre egy tetszőleges nevű publikus metódust a főosztályban, amelynek egy paramétere van
• Rendeljünk hozzá egy EntityCommand attribútumot. Az attribútum első paramétere a új menüpont neve, második paramétere az az adattípus, amelyhez az új menüpontot rendeljük. Ez lehet: Vevő, Szállító, Termék, Bizonylatok/bizonylattípusok

[EntityCommand("Vevő keresése az interneten", EntityCommandLocation.Customer)]
public void SearchCustomer(long id)

{

write code here…

}

Megjegyzések:

A főosztály GetMethodIcon metódusának felülírásával az újonnan létrehozott ribbon gombhoz ikont is rendelhetünk.

A ribbon gombhoz tartozó kód létrehozhat új ablakot vagy ablakokat.

• Hozzunk létre egy tetszőleges nevű publikus metódust a főosztályban, amelynek nincs paramétere
• Rendeljünk hozzá egy MenuCommand attribútumot. Az attribútum első paramétere a új menüpont neve, második opcionális paraméter az új menüpont helye. A második paraméter alapértelmezett értéke MenuCommandLocation.None, amely az új menüpontot a SyX főmenübe helyezi.

[MenuCommand("HelloWorld: Homokóra menüpont", MenuCommandLocation.Tools)]
public void UseWaitCursor()
{
    write code here…
}

Megjegyzések:

A főosztály GetMethodIcon metódusának felülírásával az újonnan létrehozott menüponthoz ikont is rendelhetünk.

Az új menüpont szerepelhet a Kedvencek menüben is.

A metódushoz tartozó kód létrehozhat új ablakot vagy ablakokat.

Amennyiben a menüpont neve sortörést tartalmaz (\n), úgy a menüpont almenü(k)ben jelenik meg.