Információk webprogramozóknak
A neve ellenére ez nem egy egyszerű webszerviz, hanem egy http protokollal működő egyszerű szerver, ami bizonyos kérdésekre egy webszerviznek megfelelő választ tud adni.
Alapvető különbség, hogy a parancs nélküli http get kérdésre webszerverként válaszol, azaz az nm webfelület login oldalát küldi és nem a stíluslap információit. Ennek egyik oka az, hogy a machinátor listagenerátorára épül, azaz annak az összes lekérdezése elérhető így, és ha a (pillanatnyilag) 197 lekérdezés összes input és output variációját legeneránánk egy xdi-ben, az kezelhetetlen lenne.
Ennek megfelelően nem a machinátor adatállománya érhető el ezen keresztül, hanem előre definiált lekérdezések futtatására van lehetőség. A listgenerátor struktúrájából adódóan pedig elég gyorsan tudunk az egyedi igényeknek megfelelő lekérdezéseket összeállítani.
A szerviz megszólítására ( a böngészőn kívül ) három különböző lehetőség van:
1. Http query mód
Ebben az esetben a kérdés érkezhet get-el vagy post-al is. A parancs: /LGQUERY.
A paraméterek a protokolnak megfelelő formában a parancs után jönnek. pl.:
"/LGQUERY?Listanév=Web+Termektorzs+Lista&LeirasGyujto=&KepekGyujto=&CkBesl=&PrnForma=HTML"
Lehetőség van a webservice kötetétől eltérő kötet lekérdezésére. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URL enconding ) Pl.: a "C#" kötethez: "/LGQUERY_C%23", a "C$" kötethez: "/LGQUERY_C%24"....
2. Szöveges mód
A kérésnek post-al kell érkeznie, a parancs /LGTXT.
A paraméterek a http csomag törzsében egyszerű szövegként jöhetnek. Formájuk : ParamNév=Érték[CR]vagy[LF]vagy mindkettő. Pl.:
Listanév=Web Termektorzs Lista
LeirasGyujto=
KepekGyujto=
CkBesl=
PrnForma=CSV - csak adatok
A kódolás ( content-encoding ) pillanatnyilag csak windows-1250 lehet, további kódlapok fejlesztés alatt állnak.
Lehetőség van a webservice kötetétől eltérő kötet lekérdezésére. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/LGTXT_C%23", a "C$" kötethez: "/LGTXT_C%24"....
3. XML mód
A kérésnek post-al kell érkeznie, a parancs /LGXML.
A paraméterek a http csomag törzsében XML-ként érkeznek. Pl.:
<?xml version="1.0" encoding="windows-1250" ?>
<LG_input_parameters>
<Listanév>Web Termektorzs Lista</Listanév>
<Input Nev="LeirasGyujto" />
<Input Nev="KepekGyujto" />
<Input Nev="CkBes" />
<Parameter Nev="PrnForma">XML</Parameter>
</LG_input_parameters>
Az xml bármilyen kódolású lehet.
A válasz többféle lehet a "PrnForma" paraméter értékének megfelelően:
- "CSV", "CSV - csak adatok"
- "Fix széles", "Fix széles - csak adatok"
- "Tabulátorral tagolt", "Tabulátorral tagolt - csak adatok"
- "HTML", "HTML táblázatként"
- "XML"
A "csak adatot" kitétel kihagyja a fejlécet, és az első adatsorral kezdi a válasz, a "HTML táblázatként" nem töri az adatsorokat.
Az output alapértelmezett kódolása UTF-8, az xml kivételével a válasz törzse a BOM-al kezdődik. A lekérdezések definiálásánál bármilyen kódlap egyedileg beállítható.
Lehetőség van a webservice kötetétől eltérő kötet lekérdezésére. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/LGXML_C%23", a "C$" kötethez: "/LGXML_C%24"....
A fentiekből látszik, hogy a http post-al érkező /LGXML parancs, és PrnForma=XML paraméter hatására működik a funkció egy webszerviznek megfefelően.
A program szemszögéből ez a funkció egy egyszerű "akció", mint pl. a Raktárforgalom generálás, vagy a Vevőszámlázás, azaz nem a Machinátor szerver része. Ezért egy terminál szükséges az elindításához, de sebesség optimalizálása érdekében a szerverrel azonos számítógépen, és 'Local Driver"-el. Erre legegyszerűbb a telepítő által felajánlott "WebServer terminál" amit a Machinátor szerver automatikusan létrehoz, elindít és leállít.
Alaphelyzetben a lekérdezések sebessége nem növelhető több egyidejű lekérdezés futtatásával, mivel a Machinátor struktúrája olyan, hogy egy terminál egy időben csak egy kérdést intézhet a szerverhez, ezért a webszerviz sorba állítja az érkező http kéréseket, és egymás után fogja végrehajtani őket. Azonban a Több szálon futó webszerviz alkalmazásával elérhető, hogy egyszerre több lekérdezés futhasson, így az egyes lekérdezések sebessége növelhető, mivel nem kell egymásra várniuk.
A biztonságról
A funkció alapszintű http azonosítást használ (Basic Authorization), ezt a későbbiekben a böngészős elérésben szeretnénk a jogosultság kezelésére használni, azaz nem igazán biztonsági célokat szolgál. Viszont minden kérés http fejlécében szerepelnie kell a UserID/Password-nek, ami annak a felhasználónak a machinátoros felhasználóneve/jelszava, aki a szervizt elindította. A további fejlesztések során biztosítani fogjuk, hogy ez a közvetlen ( nem böngészős ) elérésre alkalmas maradjon.
Az automatikus indítású terminál esetén az alapértelmezett: WebServer/WEBSERVER, de ezt a Machinátor rendszergazdája át tudja bármire írni, a véglegesen használt nevet jelszavat egyeztetni kell vele.
A szerviz pillanatnyilag nem tud ssl protokollt használni.
Általában a Port Forward egyetlen külső IP-re való szűkítése a betörések ellen kellő védelmet biztosít, az átmenő adatok pedig mivel egy webshop felületén úgyis megjelennek nem igazán igényelnek titkosítást. Ha mégis szükség lenne magasabb biztonsági szintre, VPN kapcsolat kialakítását tudjuk javasolni.
A sebességről
A lekérdezések sebességét nagyban befolyásolják különböző tényezők, ezért nem javasoljuk, hogy a machinátort full online adabázisként használják. Persze vannak olyan esetek ( mennyiség, ügyfélár, ügyfél rendelés lista) amit nem lehet másként megoldani, ezeket megfelelő konfigurálással lehet optimalizálni. Mindenképpen egyeztetni kell a machinátort üzemeltetővel, hogy milyen készletadatokat szeretne látni a webshopban, és hogyan gondolta a kategórizálást.
Ha a cikkek kategórizálását a machinátor cikk besorolásával akarják megoldani, úgy ha egy besorolás törzs egy tétele a kategória, akkor a leválogatás nagyságrendekkel gyorsabb, mint ha egy besorolás képletet kell vizsgálni. Ezzel a mennyiség lekérdezés egy-egy kategóriára szűkítve jó sebbéggel futhat.
Ha a mennnyiség a machinátorban nyilvántartott tényleges készlet akkor ez szintén nagyságrendekkel gyorsabb, mint a bővített készlet.
Az ügyfélár meghatározás elég bonyolult a machinátorban arra csak az lehet az optimalizálás, ha egyszerű engedményrendszer van a háttérben.
Javasolt konfiguráció
Cikktörzs
Mivel a mennyiség és ár lekérdezés időkritikus, ezért érdemes a cikktörzset az összes szükséges adattal a webshop oldalán is tárolni. A machinátorban a cikkszám / cikkcsoport az egyedi azonosítója, de a cikkcsoport elhagyható. A cikkszám max. 15 karakter hosszú lehet.
A mennyiség és ár lekérdezésnél már csak a cikkszám szerepel mint azonosító. A cikk többi adatát egy nagyobb lekérdezés szinkronizálhatja időzítve indítva. ( A machinátor az adatállományairól nem tartja nyilván külön a változásokat, illetve igen, csak a jelen esetben az erre a célra nem használható, azaz mindig a teljes lista lekérdezésére van csak lehetőség.)
Ügyféltörzs
Az ügyfélről a machinátorban is lehet egy loginnév/jelszó párost tárolni, ez alapján megoldható online is az ügyfél azonosítás, de az ügyfél adatok megváltoztatására ezen a felülenten jelenleg nincs lehetőség. (Eddig nem volt rá igény, de természetesen kialakítható az ügyfél felvétel és az adat módosítás is!) Ezért az ügyfél adatokat is tárolni kell a webshop oldalán. A rendelés felvételénél van lehetőség úgy ügyfél felvételére is, de csak korlátozott adattartalommal, és gondoskodni kell róla, hogy az ügyfélkód a machinátorban még ne létezzen. Az ügyfélkód az egyedi azonosító nyolc karakter hosszú csak számjegyek. Az ügyfél adatokat szintén egy időzített lekérdezéssel érdemes szinkronizálni.
Az ügyfélhez kapcsolódóan lehet telephely, személy... lekérdezés is, az igények szerint.
A mennyiség/ügyfélár lekérdezése
Ez egy ktitikus kérdés a futási időt tekintve. Egyik partnerünk azt a megoldást alkalmazta, hogy a felhasználó bejelentkezésekor lekérdez egy ügyfél árlistát, ami tartalmazza és aktualizálja a mennyiségeket is. Ekkor a felhasználó is inkább hajlamos másodperceket várni. (A lekérdezés az Ő esetükben ötezres cikktörzsel, bővített készlettel, de egyszerű árképzéssel kb 1000-1500 milisec. Ez tényleges készlettel kb 400-500 milisec lenne. ) Ezek után is lehet egy-egy cikkre mennyiség ellenőrzést futtatni, pl mikor a kosárba teszi a felhasználó, ez 100 milices-es idő alatt lefut.
Másik legoldás az lehet, hogy egy-egy kategóriára fut le az ár és mennnyiség lekérdezés, amikor az adott kategóriát a felhasználó megnyitja. Ebben az esetben viszont figyelembe kell venni azt, amit fent a sebesség optimalizálásról írtunk. Ha egy kategóriát ki lehet szűrni egyetlen besorolással, és a tényleges készlet érték jó, akkor a cikkek számától függően 200-500 milisec ( 30db-300db) lehet a válaszidő, ami alkalmas lehet online módra. Viszont egy besorolás képletes szűrésnél, bővített készlettel ez akár 2-3 mp is lehet, ami alkalmatlan erre.
Összeségében megfelelő feltételek mellet alkalmazható az online lekérdezés, de bonyolított esetben inkább egy a navigálástól független megoldás javasolható. Az árakra az ügyfél bejelentkezésekor alkalmazott megoldás jó, de bővített készlet esetében a mennyiségre inkább külön lekérdezés lenne célszerű olyan módon hogy ne akassza meg a webshop-ot.
Rendelések lekérdezése
Tapasztalatink szerint minden további nélkül alkalmazható online módban, több száz rendelés esetén is max egy másodperc alatt lefut, és az ügyfelek is hajlandóak egy ilyen funkcióra egy kicsit többet várni.
A lekérdezések közben fellépő hiba esetén a szervíz 500-as (Internal Server Error) HTTPResponseCode-al válaszol és a ResponseText-be beletesz egy rövid magyarázatot. Ezek a következőek lehetnek:
A(z) xxx input hiányzik : Az xxx kötelező input mező nincs megadva
Lista hiba : Az sy_lgact futtatásakor ez az "Akarja folytatni a feldolgozást?" kérdéssel járó hiba. Általában hibás LG.INI illetve hiányos importálás esetén fordul elő.
Akció hiba : Az sy_lgact futtatásakor akció hiba fordult elő.
Ezen túl a szervíz a log file-ba (WebService.Log) is rögzíti a hibát, és a kapott xml-t.
Rendelés felvétel
Ez jelenleg csak a webszerviz szerű XML lekérdezés kereteiben működő funkció.
A parancs: /ORDER
Webhop vevőrendelés XML formátum
Mit az a struktúrából is kiderül lehetőség van egyszerre több rendelés felvételére, de ez esetben az esetleges hibák nehezebben felderíthetőek.
Az itt felsorolt fizetési mód kódok menü paraméterrel megváltoztathatóak.
Lehetőség van a felvett rendelés automatikus diszponálására is, ehhez az SY_WEB akcióhoz kell megadni a megfelelő menü paramétereket.
A dátum mezők mellékes, hogy milyen szeparátor karaktert tartalmaznak, csak a pozícióknak kell egyeznie.
A válasz XML szerkezete:
<?xml version="1.0" encoding="Windows-1250" ?>
<RESPONSE>
<PARTNER_ADDED> Ügyfélkód </PARTNER_ADDED> <!-- Új ügyfél felvételének nyugtázása -->
<ORDER_ADDED> Rendelésszám </ORDER_ADDED> <!-- Rendelés felvételének nyugtázása -->
<INVALID_XML/> <!-- A kapott XML sérült, vagy hibás -->
<MISSING> Mezőnév </MISSING> <!-- Hiányzó mező -->
<INVALID_PRODUCT_CODE> Cikkszám </INVALID_PRODUCT_CODE> <!-- A megadott cikkszám nem létezik -->
</RESPONSE>
A feldolgozás csak azokat a rendeléseket hagyja ki, amelyekben hiba fordult elő, a többit felveszi.
Egy rendelés feldolgozása az első hibánál leáll, így vagy ORDER_ADDED, vagy valamilyen hiba node-ot eredményez a válaszban. Ezért ezeknek a node-oknak a sorrendjéből beazonosítható, hogy mely rendelés felvétele volt sikeres és melyik nem.
Ha a feldolgozás eljut az XML beolvasásáig, akkor válasz HTTPResponseCode: 200 (OK), csak az eremény XML feldolgozásával dönthető el, hogy sikeres volt-e rendelés(ek) felvétele.
Lehetőség van a webservice kötetétől eltérő kötetbe felvenni a rendelést. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/ORDER_C%23", a "C$" kötethez: "/ORDER_C%24"....
Minta php:
A $xml_data-ba elő kell készíteni a rendelés(ek) xml-jét, a $response fogja tartalmazni a válasz xml-t.
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL,'http://teszt.url.hu/ORDER');
curl_setopt($curl, CURLOPT_USERPWD, 'felhasznalonev:jelszo' );
curl_setopt($curl, CURLOPT_MUTE, 1);
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_HTTPHEADER, array('Content-Type: text/xml'));
curl_setopt($curl, CURLOPT_POSTFIELDS, "$xml_data");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($curl);
curl_close($curl);
Szállítólevél felvétel
Ez jelenleg csak a webszerviz szerű XML lekérdezés kereteiben működő funkció.
A parancs: /STOCK
WebShop szállítólevél XML formátum
Mit az a struktúrából is kiderül lehetőség van egyszerre több szállítólevél felvételére, de ez esetben az esetleges hibák nehezebben felderíthetőek.
A dátum mezők mellékes, hogy milyen szeparátor karaktert tartalmaznak, csak a pozícióknak kell egyeznie.
A válasz XML szerkezete:
<?xml version="1.0" encoding="Windows-1250" ?>
<RESPONSE>
<PARTNER_ADDED> Ügyfélkód </PARTNER_ADDED> <!-- Új ügyfél felvételének nyugtázása -->
<STOCK_TRAFFIC_ADDED>123412345678</STOCK_TRAFFIC_ADDED> <!-- Szállítólevél száma (Mozgásnem/Bizonylatszám) elválasztó karakterek nélkül. -->
<INVALID_XML/> <!-- A kapott XML sérült, vagy hibás -->
<MISSING> Mezőnév </MISSING> <!-- Hiányzó mező -->
<INVALID_PRODUCT_CODE> Cikkszám </INVALID_PRODUCT_CODE> <!-- A megadott cikkszám nem létezik -->
</RESPONSE>
A feldolgozás csak azokat a szállítóleveleket hagyja ki, amelyekben hiba fordult elő, a többit felveszi.
Egy szállítólevél feldolgozása az első hibánál leáll, így vagy STOCK_TRAFFIC_ADDED, vagy valamilyen hiba node-ot eredményez a válaszban.
Ha a feldolgozás eljut az XML beolvasásáig, akkor válasz HTTPResponseCode: 200 (OK), csak az eredmény XML feldolgozásával dönthető el, hogy sikeres volt-e szállítólevél(ek) felvétele.
Lehetőség van a webservice kötetétől eltérő kötetbe felvenni a szállítólevelet. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/STOCK_C%23", a "C$" kötethez: "/STOCK_C%24"....
Ügyfél lekérdezés/felvétel
Ez jelenleg csak a webszerviz szerű XML lekérdezés kereteiben működő funkció.
Methold: POST
A parancs: /PARTNER
Itt lehetőség van egy-egy ügyfél alap adatainak gyors lekérdezésére, illetve új ügyfél/telephely/személy felvételére.
Ha a webszervízhez menüparaméterként (RegÜgyfBes) meg van adva egy ügyfél besorolás tétel kódja, akkor az itt lekérdezett/felvett ügyfelekhez ezt beállítja. Értelem szerűen itt egy "Webshopban regisztrált" törzs "Igen" tételét érdemes megadni.
Lehetőség van a webservice kötetétől eltérő kötet ügyféltörzsének elérésére. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/PARTNER_C%23", a "C$" kötethez: "/PARTNER_C%24"....
Számla felvétel
Ez jelenleg csak a webszerviz szerű XML lekérdezés kereteiben működő funkció. Készletkezelés nélkül vesz egy egy vevőszámlát.
A parancs: /INVOICE, előlegszámla (díjbekérő) esetén /PREPAY
Lehetőség van a webservice kötetétől eltérő kötetbe is számla felvételre. Ez esetben a parancs mögé egy "_" karakter után kell tenni a kötetjelet.
Mivel a machinátoros kötetjelek tartalmazhatnak speciális karaktereket, ezért ezeket az RFC 3986 szabvány szerint kell kódolni! ( percent encoding / URI enconding ) Pl.: a "C#" kötethez: "/INVOICE_C%23", a "C$" kötethez: "/INVOICE_C%24"....
A kérdés törzsében egy apeh xml számlának kell lennie. Részletesebb leírást lásd: VV_SZXML
A válasz XML szerkezete:
<?xml version="1.0" encoding="windows-1250" ?>
<RESPONSE>
<INVOICE_ADDED> Számlaszám</INVOICE_ADDED> <!-- Számla felvételének nyugtázása -->
<INVALID_XML/> <!-- A kapott XML sérült, vagy hibás -->
<INVOICE_ALREADY_EXISTS/> <!-- A kapott számla már létezik a machinátorban -->
</RESPONSE>
Ha a feldolgozás eljut az XML beolvasásáig, akkor válasz HTTPResponseCode: 200 (OK).
Példa (xml) lekérdezésekre:
Cikktörzs szinkronizáció
Kérdés:
<?xml version="1.0" encoding="UTF-8"?>
<LG_input_parameters>
<Listanev>WebService Cikk Minta</Listanev>
<Parameter Nev="PrnForma">XML</Parameter>
</LG_input_parameters>
Válasz:
<?xml version="1.0" encoding="UTF-8"?>
<WebService_Cikk_Minta>
<Head>
<CopyRight>Nagy Machinátor v3.1.94.46297 2016.07.06. Sorszám: 4937 - Copyright (C) ProgEn Kft.</CopyRight>
</Head>
<Items>
<Item>
<Cikkszam>0149105</Cikkszam>
<CikkszamForm>01-49105</CikkszamForm>
<Nev>Szüzpecsenye</Nev>
<Nev2></Nev2>
<Vonalkod>12345678901201</Vonalkod>
<AlapAr>1.200</AlapAr>
<Mertekegyseg>kg</Mertekegyseg>
<Afakod>27%</Afakod>
<Tomeg>1</Tomeg>
</Item>
<Item>
<Cikkszam>0149106</Cikkszam>
<CikkszamForm>01-49106</CikkszamForm>
<Nev>Sertés egész karaj</Nev>
<Nev2></Nev2>
<Vonalkod>20087784</Vonalkod>
<AlapAr>1562</AlapAr>
<Mertekegyseg>kg</Mertekegyseg>
<Afakod>27%</Afakod>
<Tomeg>1</Tomeg>
</Item>
</Items>
</WebService_Cikk_Minta>
Ügyféltörzs szinkronizáció
Kérdés:
<?xml version="1.0" encoding="UTF-8"?>
<LG_input_parameters>
<Listanev>WebService Ugyfel Minta</Listanev>
<Parameter Nev="PrnForma">XML</Parameter>
</LG_input_parameters>
Válasz:
<?xml version="1.0" encoding="UTF-8"?>
<WebService_Ugyfel_Minta>
<Head>
<CopyRight>Nagy Machinátor v3.1.94.46297 2016.07.06. Sorszám: 4937 - Copyright (C) ProgEn Kft.</CopyRight>
</Head>
<Items>
<Item>
<Kod>99999999</Kod>
<KodForm>99-999999</KodForm>
<Nev>WebShop Teszt User</Nev>
<Irszam>1111</Irszam>
<Helyseg>Budapest</Helyseg>
<Cim>Seholnemvolt utca 1</Cim>
<Telefon>Telefon</Telefon>
<Fax>Fax</Fax>
<Adoszam>12345678-9-01</Adoszam>
<Megjegyzes>Megjegyzés</Megjegyzes>
</Item>
</Items>
</WebService_Ugyfel_Minta>
Készlet lekérdezés
Kérdés:
<?xml version="1.0" encoding="UTF-8"?>
<LG_input_parameters>
<Listanev>WebService Keszlet Minta</Listanev>
<Parameter Nev="PrnForma">XML</Parameter>
</LG_input_parameters>
Válasz:
<?xml version="1.0" encoding="UTF-8"?>
<WebService_Keszlet_Minta>
<Head>
<CopyRight>Nagy Machinátor v3.1.94.46297 2016.07.06. Sorszám: 4937 - Copyright (C) ProgEn Kft.</CopyRight>
</Head>
<Items>
<Item>
<Cikkszam>0149105</Cikkszam>
<Mennyiseg>120</Mennyiseg>
</Item>
<Item>
<Cikkszam>0149106</Cikkszam>
<Mennyiseg>10</Mennyiseg>
</Item>
</Items>
</WebService_Keszlet_Minta>
Fejlesztés és tesztelés
A machinátor webserver komponense nincs hardware kulcshoz kötve, így anélkül, demó módban is működik. Ezért lehetőség van arra, hogy a fejlesztés elején a helyszínén egy lokális gépre feltelepítve az ügyfél adatbázisával életszerű működést szimuláljon.
A 3.1.64-es verziótól kezdve szoftveres termékkulcsot használunk, az ez utáni verziókban un. lekérdező kulccsal van lehetőség helyi tesztelésre.
A fejlesztés későbbi szakaszában pedig az éles machinátor szerveren egy külön kötet felvételével ( melynek akár a cikk és ügyféltörzse át van irányítva az éles állományra ) a teszt időszakban felvett rendelések elkülöníthetőek.
Javaslataink az ügyfeleink számára
1.Ha a cikkek WebShop-ban való kategórizálását a cikk besorolással szeretnék megoldani, akkor egy külön besorolás törzsben tegyék ezt meg, és ez alá tételként az egyes kategóriákat kell felvenni. Pl.: Törzs: "WebShop kategória" ( "Nem kötelező", "Egyedi"), a tételek: "Kategória1", "Kategória2"... Ez esetben a cikktörzs exportba a kategóriák kódja vagy neve is átadható a webshop felé, és a cikk szűrés gyorsan megy, akár kategóriánként lehet online a mennyiség és ár lekérdezés.
2.Ha a kategórizálást a webshop oldalán oldják meg, de nem szeretnék a teljes cikktörzset átküldeni, ez eseten is vegyenek fel erre egy külön besorolást, ami alapján a cikkek gyorsan leszűrhetőek, és ez ne kizáró "Nem kerül webre", hanem egy megengedő "Webre kerül" besorolás legyen.
3.Ha bővített készletet szeretnének mennyiségként a webshop-ba átküldeni, vagy használják az előre dátumozást, akkor a mennyiség lekérdezés igen időigényes lehet, ezt már a kommunikáció tervezésénél figyelembe kell venni! Valószínűleg nem lesz online kivitelezhető a mennyiség lekérdezés, azaz a webshop-ban megjelenő készlet csak bizonyos időközönként fog frissülni. Ugyan akkor lehetőség van egy! cikk mennyiségének gyors online lekérdezésére, azaz pl. amikor a kosárba teszi a vásárló, vagy a rendelés feladása előtt.
Figyelem! Az automatikus webszerver terminál egy üres menün fut. Mielőtt ténylegesen üzembe helyeznék fel kell ezt a menüt is paraméterezni ugyan úgy, mint ahogyan a többi használt menüjük van. E nélkül a lekérdezések nem ugyan azt az árat és mennyiséget fogják visszaadni, mint amit a machinátor többi akciója.
