“Fejlesztési kisokos” bejegyzések.

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

3. HTML eredmény és Intranet

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

A WebMethod attribútummal ellátott metódusok meghívhatóvá válnak a kiválasztott TCP porton, HTTP kommunikációt használva. Kézenfekvő az igény, hogy a SaaS szolgáltatások ne csak primitív és összetett adatokat hanem HTML tartalmat is ki tudjanak szolgálni.

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.

2. SaaS metódusok definiálása

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

Kiszolgálói metódusok létrehozásához készítsünk egy tetszőleges metódust, amelyet lássunk el a WebMethod attribútummal. A WebMethod opcionális paramétere egy szolgáltatásleíró szöveg, amely a főoldalon jelenik meg a metódus linkje alatt.

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

1. SaaS = Software as a Service

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

A SyX beépülő modulok a v1.74-es verziótól alkalmasak külső kérések kiszolgálására is, azaz SaaS providerként is működnek.

 

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

Műveleti gombok egyedi listákon

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

Egyedi listák létrehozásakor (http://syx.symboltech.hu/fejlesztesi-kisokos/felhasznaloi-felulet/uj-lista-letrehozasa/) egyedi műveleti gombokra is szükség lehet. Ezeket tudjuk megvalósítani az lábbi módon.

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

SyX felhasználás korlátozása cégnév alapján

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

Szükség lehet rá, hogy a SyX beépülő futtatását cégnévhez kössük. Ha a CompanyNamePermission attribútumot használjuk, akkor az ott megadott cégnév vagy cégnevek esetén fog csak a SyX beépülő települni. Ezáltal korlátozhatjuk, hogy az értékesített SyX mely cégeknél (cégcsoportok esetén milyen kapcsolódó cégeknél) tud futni.

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

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

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

Szükséges programverzió

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

A Symbol Ügyvitel folyamatos fejlesztése miatt szükség lehet arra, hogy a SyX beépülő készítője beállítsa, hogy milyen verziója Symbol Ügyvitel szükséges a futtatáshoz. A SyX Visual Studio-ban lefordítható például a v1.70-es SDK-val, de nem fog futni olyan Symbol Ügyvitellel, amely csak 1.64-es verziószámú.

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.

Új számla létrehozása és megjelenítése

posted in: Példák - No Comments

Az alábbi kódrészlet egy új számlát hoz létre az egyetlen vagy kiválasztott számlatömbben. Vevőnek beállítja a vevők közül az elsőt, majd a számlát megjeleníti.

                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.